9a68a0a2eff4a543008fdca00391535f6e1ecf65: Bug 1466958 - Fix mochitests when run locally against an android build. r=gbrown
Chris Manchester <cmanchester@mozilla.com> - Tue, 05 Jun 2018 17:09:54 -0500 - rev 805725
Push 112753 by bmo:ato@sny.no at Fri, 08 Jun 2018 12:21:18 +0000
Bug 1466958 - Fix mochitests when run locally against an android build. r=gbrown MozReview-Commit-ID: Ie6665xeD53
51202d93e2e34100774d030b5dbe8e15cc8d6f16: Bug 1460590 part 2 - Fix buggy tests. r=jgraham
Nicholas Hurley <hurley@mozilla.com> - Fri, 01 Jun 2018 11:39:50 -0700 - rev 805724
Push 112753 by bmo:ato@sny.no at Fri, 08 Jun 2018 12:21:18 +0000
Bug 1460590 part 2 - Fix buggy tests. r=jgraham Test 67.js was expecting us to only parse out one server-timing-metric, and ignore "junk" after. But, according to the spec, we are only to ignore junk up to the point where we see either (1) another metric, or (2) a server-timing-param. The header sent has a param (dur=123.4), and we were parsing that correctly. Test 68.js was similar, but this time there was another metric (comma- separated) in the header, which we correctly parsed. The test expected us to ignore it as "junk". MozReview-Commit-ID: 9nBhQ7nAdhX
94b826fc4ea4116d1a75f13a4b4b1483da9ef856: Bug 1460590 part 1 - Fix our parsing of Server-Timing. r=valentin
Nicholas Hurley <hurley@mozilla.com> - Fri, 01 Jun 2018 11:39:49 -0700 - rev 805723
Push 112753 by bmo:ato@sny.no at Fri, 08 Jun 2018 12:21:18 +0000
Bug 1460590 part 1 - Fix our parsing of Server-Timing. r=valentin We were erroneously looking for the first reasonably-valued server-timing-param for each name. However, that's not how it works. We should really be looking for the first server-timing-param regardless of how reasonable its value is. MozReview-Commit-ID: LwaHFyCpteU
9175cafb84bd1e6b5c56725ca88df37ee05d663d: Bug 1450449 - Part 5: Disable file:// URI checks for downloaded files and launching files from Gecko. r=jchen
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 13 May 2018 00:07:48 +0200 - rev 805722
Push 112753 by bmo:ato@sny.no at Fri, 08 Jun 2018 12:21:18 +0000
Bug 1450449 - Part 5: Disable file:// URI checks for downloaded files and launching files from Gecko. r=jchen This is a case where I disagree with Google's stance about content:// URIs. They're perfect for granting access to files that might not even be present on the file system, e.g. virtual files generated on the spot or retrieved from some database, a cloud storage provider's app granting access to files stored in the cloud, etc., as well as for being able to selectively grant access to files conceptually "owned" by a certain app, especially files within the app's private internal storage. However when considering files that don't actually "belong" to any specific app in particular and that are already being stored in a publicly accessible (modulo the READ_EXTERNAL_STORAGE permission, respectively the user granting access through the Storage Access Framework) directory somewhere within the external storage, they also have a number of drawbacks: - While in practice a number of FileProviders will "leak" the true file system path through the content:// URI they generate, the problem remains that there's no way to know for sure whether two content:// URIs received from different apps are in fact referring to the same file or not. In case of our downloads for example, content:// URIs all referring to the same file could in principle be generated * by Firefox itself * by the system Downloads app * by the system file browser app * by any other third-party file browser or similar app that the user might have installed which e.g. will needlessly clutter up any LRU lists other apps might keep. - content:// URIs obviously depend on the generating app still being installed. So even if we fixed bug 1280184, so that uninstalling Firefox would no longer remove the user's downloads, all content:// URIs generated by Firefox re- ferring to those files would become invalid anyway. - Even if the actual file is already sitting in a public directory, when accessing it through the content:// URI the receiving app still needs to explicitly persist the permissions granted for that URI, and there are some signs that you can only persist permissions for a limited number of files. For file:// URIs on the other hand the only limitation on the number of file:// URIS you can remember is the available storage space for storing those URIs, i.e. for practical purposes more or less unlimited. - content:// URIs only grant access to a specific file. If we (or possibly an add-on) started implementing saving of websites as on desktop (i.e. HTML + associated support files instead of a PDF "copy"), then receiving apps couldn't properly open those additional support files (images, style sheets, etc.) when getting a content:// URI to the main HTML file (see https://issuetracker.google.com/issues/77406791). Since we do store downloads in the public Downloads folder on the external storage by default and I believe that conceptually, those files belong to the user and not Firefox specifically, I propose to continue launching downloaded files directly through their file:// URI. To that end, we temporarily disable the corresponding StrictMode restrictions when required and restore them afterwards. MozReview-Commit-ID: LuIYIA5FSGf
eb2c61b1014ceb1ac30211e2f9651ff36bb55770: Bug 1450449 - Part 4: Starting from Nougat, install updates via content:// URIs. r=jchen
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 12 May 2018 23:34:25 +0200 - rev 805721
Push 112753 by bmo:ato@sny.no at Fri, 08 Jun 2018 12:21:18 +0000
Bug 1450449 - Part 4: Starting from Nougat, install updates via content:// URIs. r=jchen We download the update APK into the public downloads directory and normally the only relevant app consuming that URI should be the system package installer, but just to be safe we only switch usage from Nougat onward, too. MozReview-Commit-ID: GtoXMJ7NdJ3
5d0a03ae227ac7888fb200a1a88353975a374f95: Bug 1450449 - Part 3: Starting from Nougat, share images via content:// URIs. r=jchen
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 12 May 2018 23:17:38 +0200 - rev 805720
Push 112753 by bmo:ato@sny.no at Fri, 08 Jun 2018 12:21:18 +0000
Bug 1450449 - Part 3: Starting from Nougat, share images via content:// URIs. r=jchen For sharing images we download the image to a temporary file in our internal storage area. This is a perfect use case for granting temporary access to the file only via a content:// URI instead of directly exposing the real file system path. Since support for content:// URIs by arbitrary other apps might be patchy on older Android versions, though, we only start doing this from Nougat onwards. MozReview-Commit-ID: E2I1t8dZzKj
dd8790d74ceca129f42b8e59cc6d31d6048cd5ea: Bug 1450449 - Part 2: Use content:// URI for capturing images from FilePicker. r=jchen
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 12 May 2018 23:02:19 +0200 - rev 805719
Push 112753 by bmo:ato@sny.no at Fri, 08 Jun 2018 12:21:18 +0000
Bug 1450449 - Part 2: Use content:// URI for capturing images from FilePicker. r=jchen Since it is only us and the camera app who have to deal with the content:// URI, it should be safe enough to use content:// URIs on all supported versions. MozReview-Commit-ID: JMIhBRlCiA4
d4d9645e40cb93bf772054d8235c4570a3ba47d3: Bug 1450449 - Part 1: Add FileProvider. r=jchen
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 12 May 2018 22:19:08 +0200 - rev 805718
Push 112753 by bmo:ato@sny.no at Fri, 08 Jun 2018 12:21:18 +0000
Bug 1450449 - Part 1: Add FileProvider. r=jchen In case we change our thinking on launching of downloaded files and start using content:// URIs for that case as well, we already allow our FileProvider to generate URIs for the whole file system using <root-path>. This is because users can in principle move our download directory to an arbitrary location on the file system as long as it is accessible to Firefox. However not all of these locations (e.g. on a removable SD card) can be specified through the other methods of specifying available files for a FileProvider, so only the <root- path> option remains. MozReview-Commit-ID: 2UStBlU4JsG
0673137d307f3878d4cf48160cfa16efb66c25b6: Bug 1450753 - Remove XUL style overlays. r=Nika
Brendan Dahl <brendan.dahl@gmail.com> - Wed, 06 Jun 2018 15:15:25 -0700 - rev 805717
Push 112753 by bmo:ato@sny.no at Fri, 08 Jun 2018 12:21:18 +0000
Bug 1450753 - Remove XUL style overlays. r=Nika Style overlays are no longer used outside of tests. MozReview-Commit-ID: 798Id5JITAm
f2ae0027dfa4c4a5b5b8d1d92ce02accff6e6e4f: Bug 1465806 - Wait for addon manager and session restore full initialization before starting DAMP tests. r=jdescottes
Alexandre Poirot <poirot.alex@gmail.com> - Tue, 29 May 2018 11:07:08 -0700 - rev 805716
Push 112753 by bmo:ato@sny.no at Fri, 08 Jun 2018 12:21:18 +0000
Bug 1465806 - Wait for addon manager and session restore full initialization before starting DAMP tests. r=jdescottes MozReview-Commit-ID: 1xszgL781BU
e207930f9e8a27b78e76a1866139c310e3a52dfb: Bug 1464272 - Remote Tab matches may dominate the address bar results. r=kitcambridge
Marco Bonardo <mbonardo@mozilla.com> - Wed, 06 Jun 2018 18:48:27 +0200 - rev 805715
Push 112753 by bmo:ato@sny.no at Fri, 08 Jun 2018 12:21:18 +0000
Bug 1464272 - Remote Tab matches may dominate the address bar results. r=kitcambridge MozReview-Commit-ID: HfvFvM619V5
5404016c6d164a29c8dccdce58363d5b893af565: Bug 1466863 - Just use empty metadata if invalid. r=florian
Michael Kaply <mozilla@kaply.com> - Wed, 06 Jun 2018 15:58:24 -0500 - rev 805714
Push 112753 by bmo:ato@sny.no at Fri, 08 Jun 2018 12:21:18 +0000
Bug 1466863 - Just use empty metadata if invalid. r=florian MozReview-Commit-ID: 30Q5Sdi5ZRt
18fb4c326f63eded18976a90453af328291d0f6f: Bug 1467722: Do not throw when we don't have a style, but just return an empty style. r?heycam draft
Emilio Cobos Álvarez <emilio@crisal.io> - Fri, 08 Jun 2018 11:21:59 +0200 - rev 805713
Push 112752 by bmo:emilio@crisal.io at Fri, 08 Jun 2018 12:08:30 +0000
Bug 1467722: Do not throw when we don't have a style, but just return an empty style. r?heycam We return '0' for the length, and "" for every declaration. This matches other browsers and the spec in the "no style" behavior. Of course we don't claim not to have a style for every case the spec says, but that will come later, given that's a much more risky change. This doesn't make any case where we returned something useful return something less useful, but stops null from getting returned, and returns the empty string which matches other browsers when they cannot return a style. MozReview-Commit-ID: 7Sc7HL5CgZU
4a3c6220c337fff962dc1020334a966a0d837851: Bug 1467722: Make nsComputedDOMStyle store an actual Element. r?heycam draft
Emilio Cobos Álvarez <emilio@crisal.io> - Fri, 08 Jun 2018 11:18:51 +0200 - rev 805712
Push 112752 by bmo:emilio@crisal.io at Fri, 08 Jun 2018 12:08:30 +0000
Bug 1467722: Make nsComputedDOMStyle store an actual Element. r?heycam MozReview-Commit-ID: FdfXvPARilD
8d6c47f51ca813967a5b196f2465857b633abb2b: Bug 1467722: Don't return null for getComputedStyle when there's no pres shell. r?heycam draft
Emilio Cobos Álvarez <emilio@crisal.io> - Fri, 08 Jun 2018 11:15:34 +0200 - rev 805711
Push 112752 by bmo:emilio@crisal.io at Fri, 08 Jun 2018 12:08:30 +0000
Bug 1467722: Don't return null for getComputedStyle when there's no pres shell. r?heycam We need to deal with this case regardless from getPropertyValue, and this causes pain and webcompat issues. MozReview-Commit-ID: Gbpzq0N4O2T
d821a90d646e7fc5069565b0afca60989fe07281: Bug 1467742 - update reader mode code and tests for readability updates, r?jaws draft
Gijs Kruitbosch <gijskruitbosch@gmail.com> - Fri, 08 Jun 2018 12:54:35 +0100 - rev 805710
Push 112751 by bmo:gijskruitbosch+bugs@gmail.com at Fri, 08 Jun 2018 11:55:13 +0000
Bug 1467742 - update reader mode code and tests for readability updates, r?jaws The phrasing content change means that the contents of <div id="foo> were being put in their own paragraph inside that div, and then later the singly nested <div><p></p></div> is unnested and we throw the div away, thus losing the ID attribute, which causes the browser_readerMode_with_anchor test to fail. The test document is a bit abstract and I doubt this will be an issue in practice, though I'll file a readability issue to copy the id attribute across for cases where the inner <p> has no such attribute (which would preserve the id in this case). MozReview-Commit-ID: 8XBKFiYllxY
3d361685b53f21262c93028afba1ba97553dbd5b: Bug 1467742 - update readability from github rev bf64b58d909d716770a2dd650d78286097ba797b, r?jaws draft
Gijs Kruitbosch <gijskruitbosch@gmail.com> - Fri, 08 Jun 2018 11:57:03 +0100 - rev 805709
Push 112751 by bmo:gijskruitbosch+bugs@gmail.com at Fri, 08 Jun 2018 11:55:13 +0000
Bug 1467742 - update readability from github rev bf64b58d909d716770a2dd650d78286097ba797b, r?jaws MozReview-Commit-ID: JPdLWPyToCb
1f8c48a3cab132dd8a32ce8ca3e5375bdea20809: Bug 1467536: Serialize properties flagged as SerializedByServo from getComputedStyle. r?xidorn draft
Emilio Cobos Álvarez <emilio@crisal.io> - Fri, 08 Jun 2018 10:10:45 +0200 - rev 805708
Push 112750 by bmo:emilio@crisal.io at Fri, 08 Jun 2018 11:41:43 +0000
Bug 1467536: Serialize properties flagged as SerializedByServo from getComputedStyle. r?xidorn MozReview-Commit-ID: 9hnxejljlhG
785bb9d01b25d3c773e3726c9748903787e97c38: Bug 1467536: Split GetPropertyValue from GetPropertyCSSValueWithoutWarning. r?xidorn draft
Emilio Cobos Álvarez <emilio@crisal.io> - Fri, 08 Jun 2018 10:08:44 +0200 - rev 805707
Push 112750 by bmo:emilio@crisal.io at Fri, 08 Jun 2018 11:41:43 +0000
Bug 1467536: Split GetPropertyValue from GetPropertyCSSValueWithoutWarning. r?xidorn And remove the later. MozReview-Commit-ID: BO3epOMe70w
6f7ffd3fd2047fcc79cb1ac7ed7df52a35a73714: Bug 1467536: Add CssPropFlags::SerializedByServo and use it on some simple properties. r?xidorn draft
Emilio Cobos Álvarez <emilio@crisal.io> - Thu, 07 Jun 2018 21:07:28 +0200 - rev 805706
Push 112750 by bmo:emilio@crisal.io at Fri, 08 Jun 2018 11:41:43 +0000
Bug 1467536: Add CssPropFlags::SerializedByServo and use it on some simple properties. r?xidorn The idea is to turn the simple properties into a blacklist instead really soon, and fix the offending ones soon after, so that only shorthands and properties with layout dependence (and maybe the scrollbar properties, because the poke at LookAndFeel) are not serialized by Servo. MozReview-Commit-ID: JTLNnmXzny8
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 tip