The bulk of this is adjusting the code that tries to use the toolbar to
have appropriate null checks instead of asserting it will exist. The
creation of the animator instance is now guarded by a IsFennec
condition.
Depends on D8658
Differential Revision: https://phabricator.services.mozilla.com/D8659
--HG--
extra : moz-landing-system : lando
This extracts code that is conceptually unrelated to the dynamic toolbar
from the dynamic toolbar codebase. It is a stepping stone to being able
to not instantiate the AndroidDynamicToolbarAnimator at all for
non-Fennec android products.
Differential Revision: https://phabricator.services.mozilla.com/D8657
--HG--
extra : moz-landing-system : lando
JsTerm's focus function was called in clearOutput, which
we call when navigating to a new page (if Persist Logs is
not checked).
This means that we were forcing the JsTerm to be focused
each time the user navigated while having the console open.
This behavior, can be annoying, or at worst, if you're
debugging a focus issue in your content page, completely maddening.
The fix is striaghtforward: do not call focus in clearOutput.
A test is added to make sure we don't regress this.
Differential Revision: https://phabricator.services.mozilla.com/D8701
--HG--
extra : moz-landing-system : lando
This avoids loading the remaining parts of TelemetrySession in a content process.
This saves around 10 kb of memory.
Differential Revision: https://phabricator.services.mozilla.com/D8378
--HG--
extra : moz-landing-system : lando
Note that DataViewObject had dataPointer* methods but TypedArrayObject used
viewData* for this. I used dataPointer* for consistency with ArrayBufferObject
(and I like it more).
Depends on D7721
Differential Revision: https://phabricator.services.mozilla.com/D7722
--HG--
extra : moz-landing-system : lando
Has a single caller, from which we pass the arguments. We can just avoid that.
Differential Revision: https://phabricator.services.mozilla.com/D8276
--HG--
extra : moz-landing-system : lando
I plan to change servo to use all: inherit on its UA sheet.
I hope the patch below should make it good enough performance-wise. And also,
it's probably broken so I don't think it's worth supporting it specially.
Differential Revision: https://phabricator.services.mozilla.com/D8686
--HG--
extra : moz-landing-system : lando
This makes us not allocate useless style structs when you're doing something
like resetting an already-reset property, or inheriting an already-inherited
property.
Seemed simple enough that I think we should do it. In practice we don't even
should pay an extra branch because I expect the compiler to be smart enough and
merge it with the one in the mutate() call.
Differential Revision: https://phabricator.services.mozilla.com/D8685
--HG--
extra : moz-landing-system : lando
Set layout.css.control-characters.visible to true for wpt control character tests added in bug 1497380
Differential Revision: https://phabricator.services.mozilla.com/D8697
--HG--
extra : moz-landing-system : lando
Added support for opening HTML files from internal storage when user is choosing fennec in the dialog picker.
Depends on D7167
Differential Revision: https://phabricator.services.mozilla.com/D7490
--HG--
extra : moz-landing-system : lando
* browser_addons_debug_webextension_popup: It looks like frame-update events are now fired earlier.
I had to move the listener to an earlier step in order to make it work.
* helper_disable_cache + toolbox.js: this test wasn't correctly listening for reconfigure request's end.
Not clear how this test was passing before without high rate of intermittent...
* test_webextension-addon-debugging-connect.html: We can no longer listen for frame-update *before* the target object is created.
(because we now need a TabTarget object or the TargetFront and not just the DebuggerClient)
* Fix reload request in shadereditor which may still be pending after test ends.
MozReview-Commit-ID: 49qvWSCn6nq
Depends on D8066
Differential Revision: https://phabricator.services.mozilla.com/D7460
--HG--
extra : moz-landing-system : lando
* debugger-controller and events.js are special and require to support two cases because this is
the only production codepath that can have a TabTarget or a WorkerTarget.
Thus, leading to either TargetFront or WorkerClient on target.activeTab.
* webide.js doesn't need to listen for tabNavigated, this is redundant with tabListChanged.
* application's initializer. In case you are wondering this code can't be spawn against a WorkerTarget.
The application panel doesn't work in worker toolboxes.
* The code modified in target is in TabTarget, so we don't have to support the WorkerClient case, we always have a TargetFront here.
* I tried to update the doc file the best I can but this all feel outdated.
MozReview-Commit-ID: 2hGchebfIub
Depends on D7458
Differential Revision: https://phabricator.services.mozilla.com/D7459
--HG--
extra : moz-landing-system : lando
TabClient appears to be a client for any actor that inherits from browsing context target actor.
So let it be a front for that.
MozReview-Commit-ID: KmpClxJ53N7
Depends on D7457
Differential Revision: https://phabricator.services.mozilla.com/D7458
--HG--
extra : moz-landing-system : lando
