When passing the transforms from nsDisplayTransform items down to the
descendant display items, we need to make sure they are combined properly
so that the "ancestor transform" on the APZ side is correctly computed.
MozReview-Commit-ID: Di1FBLYGef5
--HG--
extra : rebase_source : 736e7cd375681f84ca2db8e6b98bf1a7525431d4
Move the TRR blacklist check to the main thread, and since it is now
done a little later and for each separate request, make sure to only do
the telemetry counting for one of the record types (A) so that we don't
count them twice.
MozReview-Commit-ID: BgvU4TzrpCq
--HG--
extra : rebase_source : 304bc75a6f22963b51e89034de1b30506337b6ec
In Bug 1419292, we make sure there is no issue when releasing
actors for the output messages, so the sidebar is probably
good to go on Nighly in order to get more feedback.
The test for context menu entries in the console was updated
since it now shows the "Open in sidebar" entry.
MozReview-Commit-ID: 8R3rhf944Fh
--HG--
extra : rebase_source : 8fa00b58b43dea52fbbbfffc29c2cfb7960b49d0
Take into account node offsets in browser_webconsole_object_inspector_local_session_storage.js.
MozReview-Commit-ID: 73waFejjsF0
--HG--
extra : rebase_source : d34e26c280f777e266ab7f014cfb9b41e07c9a5e
OOM rust crashes are currently not identified as such in crash reports
because rust libstd handles the OOMs and panics itself.
There are unstable ways to hook into this, which unfortunately are under
active changes in rust 1.27, but we're currently on 1.24 and 1.27 is not
released yet. The APIs didn't change between 1.24 and 1.26, so it's
fine-ish to use them as long as we limit their use to those versions.
As long as the Firefox versions we ship (as opposed to downstream) use
the "right" version of rust, we're good to go.
The APIs are in their phase of stabilization, so there shouldn't be too
many variants of the code to support.
--HG--
extra : rebase_source : 08a85aa102b24380b1f6764effffcc909ef3191b
Bug 1421144 fixed IAccessible::accFocus to work when focus is within a remote document.
Unfortunately, this causes mysterious intermittent crashes when called from a UIA client in Windows 7.
Ideally, we'd deal with the actual cause of the crashes, but they seem to be deep in Windows RPC code and all attempts at tracking this down have failed.
Clients don't seem to need this too often anyway (and it's a minor annoyance if it doesn't work when they do).
MozReview-Commit-ID: IxvbBGJ2wxA
--HG--
extra : rebase_source : 504909703718b75fffcabf1fbe56c0bbff089b58
For some reason, removing the scrollbar binding triggers
content process performance regression on Linux.
We'll add an empty binding for now until we find the real cause.
MozReview-Commit-ID: 5sonOULH1x8
--HG--
extra : rebase_source : 10d9a1577f2f36937baf65b10baf29c6e2e3a114
The stacks are now correctly output by the test harness, they may not have been before.
MozReview-Commit-ID: FugywVd9xoC
--HG--
extra : rebase_source : d593415b72da65b1f08bb00ad1249db0b66ca225
Currently, it attempts to override 'ok()', but fails in doing so.
MozReview-Commit-ID: LUp6LRb1Alv
--HG--
extra : rebase_source : 4814ce5684db429af07d9ea9357aa0dedad1a390
Fix all Java warnings in the Android codebase except deprecation and
serial warnings, and warnings in third-party code.
There is one required change to exoplayer2 code under thirdparty,
because that code is included directly in the geckoview project, instead
of the thirdparty project. I think I'll just make a pull-request to
upstream the change, instead of separating exoplayer2 into a
gv-thirdparty project.
kotlinc emits its warning/error messages as "w: <msg>" and "e: <msg>",
which Treeherder is unable to pick up. Rather than changing Treeherder,
it's best to make the change as close to the source of the message as
possible. I looked at changing mach to redirect the output of gradle and
make adjustments as necessary, but for some reason gradle doesn't want
to work with the pipes that mach sets up. So that leaves changing the
gradle build script itself.
This patch adds some code to detect the kotlin messages, and output an
adjusted version as necessary. It has the benefit of only dealing with
kotlinc output, so output from other tools should not be inadvertently
changed. However, due to the way it is implemented, it does duplicate
every warning/error output; for example, an error would now look like
this in the terminal:
<file>: error: <msg>
e: <file>: <msg>
I think this is an acceptable drawback.
- Refactor the logic for getting the grid highlighter settings into HighlightersOverlay.js
- Refactor the grid area and cell highlight into a single function in grid-inspector.js
- Change the order of the parameters for onHighlighterChange in grid-inspector.js
- Get the last highlighted state from the Redux store instead of storing them in a variable
Extract loading the grid highlighter setting into HighlightersOverlay. This
allows the grid highlighter toggle in the rule view to also show the grid
highlighter with the currently set highlight settings if the grid inspector
has not been initiated yet.