9de39e80563d602490b342443d66e58cdb111edc: Bug 1571376 - Make all themes support non-disappearing scrollbar sizes. r=mstange
Emilio Cobos Álvarez <emilio@crisal.io> - Thu, 07 May 2020 15:28:35 +0000 - rev 528638
Push 37392 by apavel@mozilla.com at Thu, 07 May 2020 21:43:47 +0000
Bug 1571376 - Make all themes support non-disappearing scrollbar sizes. r=mstange That is, so that the select dropdown button always take the size of a native scrollbar rather than a potentially custom scrollbar. Differential Revision: https://phabricator.services.mozilla.com/D73261
0439b81b14214317210017ce6e677956f35c7497: Bug 1627026 - Use Fenix nightly build variant in perftests. r=perftest-reviewers,davehunt
Gregory Mierzwinski <gmierz2@outlook.com> - Thu, 07 May 2020 15:03:26 +0000 - rev 528637
Push 37392 by apavel@mozilla.com at Thu, 07 May 2020 21:43:47 +0000
Bug 1627026 - Use Fenix nightly build variant in perftests. r=perftest-reviewers,davehunt This patch changes the build variant we use for performance testing in raptor and browsertime from performance-test to the fennec-nightly build which is more representative of what a user might experience. Depends on D68190 Differential Revision: https://phabricator.services.mozilla.com/D72886
8e7f4d31c649ddd6a6504c22218cd488ea1a0031: Bug 1613487 - Disable Raptor-webext and enable Raptor-btime Fenix tests. r=perftest-reviewers,Bebe
Gregory Mierzwinski <gmierz2@outlook.com> - Thu, 07 May 2020 13:49:27 +0000 - rev 528636
Push 37392 by apavel@mozilla.com at Thu, 07 May 2020 21:43:47 +0000
Bug 1613487 - Disable Raptor-webext and enable Raptor-btime Fenix tests. r=perftest-reviewers,Bebe This patch does a few things: (1) Prevents Amazon and Youtube Fenix Browsertime tests from running on each push. (2) Prevents Chrome Browsertime tests from running on each push (these should only run through the cron task). (3) Prevents Speedometer Fenix Browsertime tests from running on each m-c push. (4) Replaces the Raptor Fenix speedometer test in the general cron task with the Browsertime variant. (5) Replaces the Raptor Fenix Amazon test with in the tp6m cron task with the Browsertime variant. Differential Revision: https://phabricator.services.mozilla.com/D68190
462e54ecb42307587f10d8956c3098d89108d59a: Bug 1619339 - explicitly set the soft ulimit for open files from mach; r=glandium
Nathan Froyd <froydnj@mozilla.com> - Thu, 07 May 2020 15:08:43 +0000 - rev 528635
Push 37392 by apavel@mozilla.com at Thu, 07 May 2020 21:43:47 +0000
Bug 1619339 - explicitly set the soft ulimit for open files from mach; r=glandium We do this to avoid unnecessarily penalizing subprocess invocations from within mach (and all child processes) on some Linux setups. Differential Revision: https://phabricator.services.mozilla.com/D66786
892f1e4b6cb9caed85296e05a3f2431e769f76fe: Bug 1636130 - Tracelog the activating experiment r=janerik
Chris H-C <chutten@mozilla.com> - Thu, 07 May 2020 15:08:17 +0000 - rev 528634
Push 37392 by apavel@mozilla.com at Thu, 07 May 2020 21:43:47 +0000
Bug 1636130 - Tracelog the activating experiment r=janerik Differential Revision: https://phabricator.services.mozilla.com/D74246
90d05e01c66be85e4488c2bf17307ac9994d6ca7: Reverting changes in 43625f3bc860260d31f6332b2f0b30d32de8629b services/settings/dumps/blocklists/addons-bloomfilters.json for casuing xpcshell failures. CLOSED TREE
Dorel Luca <dluca@mozilla.com> - Thu, 07 May 2020 18:14:12 +0300 - rev 528633
Push 37392 by apavel@mozilla.com at Thu, 07 May 2020 21:43:47 +0000
Reverting changes in 43625f3bc860260d31f6332b2f0b30d32de8629b services/settings/dumps/blocklists/addons-bloomfilters.json for casuing xpcshell failures. CLOSED TREE
5107c36695a73f96a7cd12c0a68a2d23dec631ff: Bug 1635937 - Enable 'identity.sync.useOAuthForSyncToken' pref for Nightly users r=rfkelly
Vlad Filippov <vlad.filippov@gmail.com> - Thu, 07 May 2020 14:36:46 +0000 - rev 528632
Push 37392 by apavel@mozilla.com at Thu, 07 May 2020 21:43:47 +0000
Bug 1635937 - Enable 'identity.sync.useOAuthForSyncToken' pref for Nightly users r=rfkelly Differential Revision: https://phabricator.services.mozilla.com/D74145
5d44a9bea183dc551abc61caeff07d388e3403dc: Bug 1634737 - GeneratedFile() template should yell at you if you try to set py2=True r=glandium
Ricky Stewart <rstewart@mozilla.com> - Tue, 05 May 2020 15:53:37 +0000 - rev 528631
Push 37392 by apavel@mozilla.com at Thu, 07 May 2020 21:43:47 +0000
Bug 1634737 - GeneratedFile() template should yell at you if you try to set py2=True r=glandium As of bug 1621451 this argument was ignored, but it just silently runs your code with `python3` if you pass it anyway. Ensure this doesn't happen any more, and protect against any other unexpected arguments as well. Differential Revision: https://phabricator.services.mozilla.com/D73485
9d9bb7c3e80604d8be0d46974cd1a46f1f12fa02: Bug 1633156 - Don't emit cached table files from ply r=glandium
Ricky Stewart <rstewart@mozilla.com> - Thu, 07 May 2020 00:39:28 +0000 - rev 528630
Push 37392 by apavel@mozilla.com at Thu, 07 May 2020 21:43:47 +0000
Bug 1633156 - Don't emit cached table files from ply r=glandium `ply`, [by design](https://github.com/dabeaz/ply/issues/79), does not produce reproducible table files; hence bug 1633156. (Note that this was *always* true, but only became a problem once we switched to Python 3, which has more unpredictable dict iteration order than Python 2.7, at least prior to [3.7](https://docs.python.org/3/whatsnew/3.7.html#summary-release-highlights).) In any other circumstance I would consider submitting a patch to `ply` to fix this, but as of the [in-progress version 4.0 of the library](https://github.com/dabeaz/ply/blob/master/CHANGES), it doesn't even emit this cached data any more, and indeed the [latest version of the code](https://github.com/dabeaz/ply/tree/1fac9fed647909b92f3779dd34beb8564f6f247b/ply) doesn't even call `open()` at all except to do logging or to read the text data to be parsed from `stdin`. So if we were going to pin our future on `ply` and upgrade to later versions of the library in the future, we would have to live in a world where `ply` doesn't generate cached table files for us anyway. Emitting the cached table files so later build steps can consume them is an "optimization", but it's not clear exactly how much actual value that optimization provides overall. Quoth the `CHANGES` file from that repository: ``` PLY no longer writes cached table files. Honestly, the use of the cached files made more sense when I was developing PLY on my 200Mhz PC in 2001. It's not as much as an issue now. For small to medium sized grammars, PLY should be almost instantaneous. ``` In practice, I have found this to be true; namely, `./mach build pre-export export` takes just about as long on my machine after this patch as it did before, and in a try push I performed, there's no noticeable performance regression from applying this patch. In local testing I also found that generating the LALR tables in calls to `yacc()` takes about 0.01s on my machine generally, and we generate these tables a couple dozen times total over the course of the `export` tier now. This isn't *nothing*, but in my opinion it's also not nearly long enough where it would be a concern given how long `export` already takes. That `CHANGES` file also stresses that if caching this data is important, we have the option of doing so via `pickle`. If and when we decide that re-enabling this optimization is valuable for us, we should take control of this process and perform the generation in such a way that we can guarantee reproducibility. Differential Revision: https://phabricator.services.mozilla.com/D73484
78c07ca17076dd63902f7b5ad2461bbbaf8ff504: Bug 1634535 - Move ply to third_party/python r=glandium
Ricky Stewart <rstewart@mozilla.com> - Tue, 05 May 2020 16:02:02 +0000 - rev 528629
Push 37392 by apavel@mozilla.com at Thu, 07 May 2020 21:43:47 +0000
Bug 1634535 - Move ply to third_party/python r=glandium The license used to be LGPL so the code lived in other-licenses, but it was changed to BSD eleven years ago. Let's move it over to third_party/python/ply where it belongs. ./mach vendor python ply==3.10 `diff -r` between the original `ply` directory and the new one only comes up with the new file `third_party/python/ply/CHANGES` which isn't relevant to the functionality of the code, so this should be a no-op all told. Differential Revision: https://phabricator.services.mozilla.com/D73341
8a2c548a7d283a9437fc38bfa7d35780888fe4a9: Bug 1635709: part 3) Add unit to `Selection::StartAutoScrollTimer`'s delay argument. r=hsivonen
Mirko Brodesser <mbrodesser@mozilla.com> - Wed, 06 May 2020 15:24:59 +0000 - rev 528628
Push 37392 by apavel@mozilla.com at Thu, 07 May 2020 21:43:47 +0000
Bug 1635709: part 3) Add unit to `Selection::StartAutoScrollTimer`'s delay argument. r=hsivonen Depends on D74052 Differential Revision: https://phabricator.services.mozilla.com/D74053
b8e38d56a744a1915ef5f205afabe9528f8a8eb5: Bug 1635709: part 2) Add unit to `nsITimer`'s `init` methods. r=froydnj
Mirko Brodesser <mbrodesser@mozilla.com> - Wed, 06 May 2020 15:23:22 +0000 - rev 528627
Push 37392 by apavel@mozilla.com at Thu, 07 May 2020 21:43:47 +0000
Bug 1635709: part 2) Add unit to `nsITimer`'s `init` methods. r=froydnj `Selection`'s `nsAutoScrollTimer` uses it and it's clearer when the unit is known. Depends on D74051 Differential Revision: https://phabricator.services.mozilla.com/D74052
2af59ac0778ca2f2684556edcf26aa1f36127728: Bug 1635709: part 1) Rename `nsFrameSelection::SetCaretBidiLevel` to `SetCaretBidiLevelAndMaybeSchedulePaint`. r=hsivonen
Mirko Brodesser <mbrodesser@mozilla.com> - Wed, 06 May 2020 15:26:07 +0000 - rev 528626
Push 37392 by apavel@mozilla.com at Thu, 07 May 2020 21:43:47 +0000
Bug 1635709: part 1) Rename `nsFrameSelection::SetCaretBidiLevel` to `SetCaretBidiLevelAndMaybeSchedulePaint`. r=hsivonen The old name was misleading. Differential Revision: https://phabricator.services.mozilla.com/D74051
1634aa932e28cc0e87db8c55f36d7d7d3b85f0d2: Bug 1623380 - Send ODA directly to content process r=dragana
Kershaw Chang <kershaw@mozilla.com> - Thu, 07 May 2020 14:39:21 +0000 - rev 528625
Push 37392 by apavel@mozilla.com at Thu, 07 May 2020 21:43:47 +0000
Bug 1623380 - Send ODA directly to content process r=dragana Differential Revision: https://phabricator.services.mozilla.com/D67609
58a00e6be174ea001a983189dd4f58e305305b5d: Bug 1632535 - Support asking Marionette for a os-supplied port number r=marionette-reviewers,maja_zf
Chris H-C <chutten@mozilla.com> - Thu, 07 May 2020 14:38:08 +0000 - rev 528624
Push 37392 by apavel@mozilla.com at Thu, 07 May 2020 21:43:47 +0000
Bug 1632535 - Support asking Marionette for a os-supplied port number r=marionette-reviewers,maja_zf Differential Revision: https://phabricator.services.mozilla.com/D73897
0d45875628da71dc4a3480e16d0e53961816c271: Bug 1635732: Use a worker alias for `t-linux-metal` workers; r=gbrown
Tom Prince <mozilla@hocat.ca> - Thu, 07 May 2020 14:06:15 +0000 - rev 528623
Push 37392 by apavel@mozilla.com at Thu, 07 May 2020 21:43:47 +0000
Bug 1635732: Use a worker alias for `t-linux-metal` workers; r=gbrown Differential Revision: https://phabricator.services.mozilla.com/D74188
cdcefab9cfc3eaee323cf072189be81ad4e91767: No Bug, mozilla-central repo-update HSTS HPKP remote-settings tld-suffixes - a=repo-update r=RyanVM
ffxbld <ffxbld@mozilla.com> - Thu, 07 May 2020 14:10:06 +0000 - rev 528622
Push 37392 by apavel@mozilla.com at Thu, 07 May 2020 21:43:47 +0000
No Bug, mozilla-central repo-update HSTS HPKP remote-settings tld-suffixes - a=repo-update r=RyanVM Differential Revision: https://phabricator.services.mozilla.com/D74235
43625f3bc860260d31f6332b2f0b30d32de8629b: Bug 1636004 - Flush frames in nsFrameLoader::TryRemoteBrowser. r=mattwoodrow
Emilio Cobos Álvarez <emilio@crisal.io> - Thu, 07 May 2020 13:46:16 +0000 - rev 528621
Push 37392 by apavel@mozilla.com at Thu, 07 May 2020 21:43:47 +0000
Bug 1636004 - Flush frames in nsFrameLoader::TryRemoteBrowser. r=mattwoodrow With LazyFC in the parent process enabled, we can get here more easily without frames for the <browser> element. This causes some assertion failures because we start parenting the remote browsers to the wrong layer manager when inside a popup. If we get to nsFrameLoader::TryRemoteBrowser without a frame, GetLayerManager (which uses GetWidgetForContent) will just fall back to GetWidgetForDocument. Badness ensues if the widget should actually not be that one. Make sure to flush frames when we load an event, so that we can initialize stuff properly. We could try to only flush if inside a popup or something, but this code is a bit tricky so if possible I'd prefer not to diverge. Differential Revision: https://phabricator.services.mozilla.com/D74177
3a21ee384f6d26433fa5165b9c43bb5198948196: Bug 1618636 - Replace FunctionCreationData with ScriptStencilBase. r=mgaudet
Ted Campbell <tcampbell@mozilla.com> - Thu, 07 May 2020 12:51:40 +0000 - rev 528620
Push 37392 by apavel@mozilla.com at Thu, 07 May 2020 21:43:47 +0000
Bug 1618636 - Replace FunctionCreationData with ScriptStencilBase. r=mgaudet We only use the gcThings array, but this is a stepping stone to Stencil. Differential Revision: https://phabricator.services.mozilla.com/D74158
bef58cfccdd82ec4642c078b8f22ccf67d6255d9: Bug 1618636 - Move FunctionCreationData::createLazyScript. r=mgaudet
Ted Campbell <tcampbell@mozilla.com> - Thu, 07 May 2020 12:51:38 +0000 - rev 528619
Push 37392 by apavel@mozilla.com at Thu, 07 May 2020 21:43:47 +0000
Bug 1618636 - Move FunctionCreationData::createLazyScript. r=mgaudet Differential Revision: https://phabricator.services.mozilla.com/D74157
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 tip