We need to do both of updates in the case where both updates in the same
transaction.
Differential Revision: https://phabricator.services.mozilla.com/D17582
--HG--
extra : moz-landing-system : lando
In fact, "simply" use whatever python configure does to find a shell to
execute config.guess and config.sub, and get both the mozconfig content
and the real, canonicalized target alias. This has the side effect of
making builds with --target=$cpu use a complete obj-$cpu-$os default
objdir instead of obj-$cpu. This will also allow to change the
host-guessing logic without having to duplicate code.
Differential Revision: https://phabricator.services.mozilla.com/D17618
--HG--
extra : moz-landing-system : lando
This patch applies the following changes:
- Reduce the chances of retrieving the initial popup panel size while it is resizing, by comparing the
content dimensions retrieved before and after the delay (which is already set to a value comparable
to the time used by the resize debouncing timer), and wait until both the dimensions collected are the same
- split browser_ext_browserAction_popup_resize.js into two test files (as it seems, based on the investigations
I did by reproducing this intermittent locally, that the part that can still fail intermittently from time
to time with the change describe above is related to the testBrowserActionMenuResizeBottomArrow test case)
- move the test helpers shared between the two test files into a new head_browserAction.js support file
- re-enabled browser_ext_browserAction_popup_resize.js
- mark the new browser_ext_browserAction_popup_resize_bottom.js as disabled on debug build,
because it is consistently triggering a "shutdown leak" failure when running locally
Differential Revision: https://phabricator.services.mozilla.com/D17267
--HG--
rename : browser/components/extensions/test/browser/browser_ext_browserAction_popup_resize.js => browser/components/extensions/test/browser/browser_ext_browserAction_popup_resize_bottom.js
rename : browser/components/extensions/test/browser/browser_ext_browserAction_popup_resize.js => browser/components/extensions/test/browser/head_browserAction.js
extra : moz-landing-system : lando
The desktopMode property on Fennec's tab object is already being correctly being
preserved when (re)creating a tab [1], but we don't propagate its state to the
content window's desktop viewport mode setting.
[1] When restoring into a fresh tab, the session restore code passes the stored
desktopMode flag to addTab, whereas zombifying an existing tab destroys its
<browser>, but leaves the tab object's properties intact, so we merely need to
re-set the desktop viewport mode on the new <browser>'s content window.
Differential Revision: https://phabricator.services.mozilla.com/D17774
--HG--
extra : moz-landing-system : lando
Now that form argument is no longer used by any front to set its actor ID,
we can remove this argument.
Have a particular look at:
* devtools/client/shared/test/test-actor-registry.js
which was the last Front to be manually instantiated and need some tweaks,
* canvas head.js to create canvas front via getFront,
* RDM manager.js, which requires the EmulationFront to be self managed.
Depends on D17615
Differential Revision: https://phabricator.services.mozilla.com/D17616
--HG--
extra : moz-landing-system : lando
Ideally, formAttributeName would be a field on the prototype of each front,
but unfortunately, Firefox doesn't support ES Class's fields yet. So it is
put as an instance attribute instead.
This patch streamline the manually set actorID and the retrieval of actor ID
from root or target front's form into `getFront` helper method.
So that all the specific related to the lazy actor is now inside of this helper.
It also moves the special "this.manage(this)" to this helper.
We might be able to followup on this one and finally have only the root front
being self managed. But the initialize method makes it hard.
Note the special tweak made to devtools/client/responsive.html/manager.js
Hopefully this can be removed once the target classes are merged.
Depends on D15832
Differential Revision: https://phabricator.services.mozilla.com/D17615
--HG--
extra : moz-landing-system : lando
Only a couple of special cases where expecting to pass a full form object
as Front's second constructor argument.
Refactor them to ensure calling Front's form method instead in order to align
with typical protocol.js's behavior.
Depends on D17614
Differential Revision: https://phabricator.services.mozilla.com/D15832
--HG--
extra : moz-landing-system : lando
This feature is only used by node and domrulestyle actors and that, only for actor ID.
Instead of this, support this "pass only actor ID rather than full form" feature
in a more dedicated way.
We might followup on that to clarify/simplify doing this: passing only the actor ID
rather than its full form.
Depends on D17613
Differential Revision: https://phabricator.services.mozilla.com/D17614
--HG--
extra : moz-landing-system : lando
Remove all actorid checks in actors and fronts as we never pass a defined `detail` argument in them.
Only domstylerule and node are using detail and that, always with detail="actorid".
Also remove ctx and detail in Front constructor as that's not used by these two actors.
Depends on D17612
Differential Revision: https://phabricator.services.mozilla.com/D17613
--HG--
extra : moz-landing-system : lando
None of our actor define a `formType` in its specification.
This feature has never been used, so remove it and its test.
Differential Revision: https://phabricator.services.mozilla.com/D17612
--HG--
extra : moz-landing-system : lando
There are cases where we might want to set this from a non-URL bar user action -
for example, when clicking on the Home button.
Differential Revision: https://phabricator.services.mozilla.com/D17407
--HG--
extra : moz-landing-system : lando
The language pack job specifically was failing becuase of trunk versioning attempting to submit to AMO, while it
should not have even run on central, especially not in an on-push job. Additionally this stops other related jobs
like devedition and beetmover from running for cedar.
Differential Revision: https://phabricator.services.mozilla.com/D17821
--HG--
extra : moz-landing-system : lando
This was lost in the change to only use the visual viewport if both the
size and offset were set.
Differential Revision: https://phabricator.services.mozilla.com/D17752
--HG--
extra : moz-landing-system : lando
This changes the policy to use the pref and permissions rather than a boolean flag. Using permissions gets us proper settings on startup without introducing any new overhead. Going this way flips our tests around so rather than testing an override to turn off private browsing support, we test overrides to enable private browsing support.
Differential Revision: https://phabricator.services.mozilla.com/D14482
--HG--
extra : moz-landing-system : lando
The interpreter will use this to set the frame's ICEntry* pointer at jump target
ops and then it will just bump this pointer after each JOF_IC op. This way the
interpreter can use Baseline ICs with minimal overhead compared to the Baseline
JIT.
Differential Revision: https://phabricator.services.mozilla.com/D17115
--HG--
extra : moz-landing-system : lando
We use foreground services, so this is necessary in order to be able to target
Android P.
The GeckoView example app needs it for the crash handling service.
Differential Revision: https://phabricator.services.mozilla.com/D16423
--HG--
extra : moz-landing-system : lando
android.test.* is no longer part of the main framework, so as per
https://developer.android.com/training/testing/set-up-project,
- we must no longer declare them as a *required* dependency in our manifests
- we must explicitly include a dependency on them in our build config
This will temporarily break running tests depending on android.test.* (i.e.
mainly Robocop) on devices using P or newer until we also start targeting P as
well.
Differential Revision: https://phabricator.services.mozilla.com/D16422
--HG--
extra : moz-landing-system : lando
Once we start compiling with API28, android.test.* is no longer part of the main
framework JAR and will be included from separate libraries instead.
Those additional JARs will then subsequently show up on the class path in
Gradle, too.
Because our SDKProcessor is currently set up to process only one JAR at a time
and because we don't actually need to generate bindings for those test classes,
we simply filter them out again.
We explicitly only filter the android.test.* JARs and use findAll so that if the
android classpath unexpectedly gains another member, we're alerted to that fact
and can consciously take a decision on whether to ignore it as well or not.
Differential Revision: https://phabricator.services.mozilla.com/D16421
--HG--
extra : moz-landing-system : lando
This patch cleans up the assertion added in bug 1426492.
With that we have disallowed all bindings in content HTML.
The XMLPrettyPrint binding was removed in bug 1503019.
Depends on D17575
Differential Revision: https://phabricator.services.mozilla.com/D17576
--HG--
extra : moz-landing-system : lando
With all the dependency removed this pref can be safely removed.
Depends on D17574
Differential Revision: https://phabricator.services.mozilla.com/D17575
--HG--
extra : moz-landing-system : lando
This patch removes the XBL pluginProblem binding and have the in-content
UI always created by the UA Widget.
Depends on D17573
Differential Revision: https://phabricator.services.mozilla.com/D17574
--HG--
extra : moz-landing-system : lando
This patch removes the XBL marquee binding and always uses
UA Widget for the internal "gut" of the marquee element.
Depends on D17572
Differential Revision: https://phabricator.services.mozilla.com/D17573
--HG--
extra : moz-landing-system : lando
This patch removes the datetimebox binding and always use
UA Widget for the job.
Depends on D17571
Differential Revision: https://phabricator.services.mozilla.com/D17572
--HG--
extra : moz-landing-system : lando
This patch removes the XBL videocontrols binding and make <video>
to always use the UA Widget to generate controls.
DevTools tests that look for NAC is switched to use <input type=file>.
Differential Revision: https://phabricator.services.mozilla.com/D17571
--HG--
extra : moz-landing-system : lando
This custom element replaces XBL <content> usage by directly prepend the two needed child nodes when the element is connected.
This is doable because
- There isn't any direct access of child nodes under <menulist>. Everyone seems to access via .menupopup, which is usually the only child.
- We don't need to move the children under <menulist>. If we need to and if the child is a <xbl:children> (which could happen if <menulist> is inside an XBL <content> that just get cloned to the document), the layout will get very confused and crash (see finding in bug 1514926)
Differential Revision: https://phabricator.services.mozilla.com/D16149
--HG--
rename : toolkit/content/widgets/menulist.xml => toolkit/content/widgets/menulist.js
extra : moz-landing-system : lando
Because custom elements will be constructed when DOM is constructed,
construct the DOM in the hidden panels will be expensive as we move
more and more widgets to custom elements from XBL.
This patch attempts to counter that by moving all the pane markups
into comment nodes, and use MozXULElement.parseXULToFragment() to
insert it when it is being asked.
They will be loaded lazily from an requestIdleCallback() in findInPage.js.
Differential Revision: https://phabricator.services.mozilla.com/D16787
--HG--
extra : moz-landing-system : lando
JSOP_LABEL isn't a jump instruction at all. This patch adds JOF_CODE_OFFSET and
uses it for JSOP_LABEL. This lets us simplify some code and avoids a rooting
hazard with the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D17842
--HG--
extra : moz-landing-system : lando
The problem here is that the MediaStreamGraphImpl::mInputDeviceID is not reset after a device unplug. On a device-remove event of the active device MediaStreamGraphImpl::mInputDeviceID is reset when MediaStreamGraphImpl::CloseAudioInput is being executed. This method will not be executed if the new enumeration, on the MediaManager::OnDeviceChange, is returning the old outdated list of devices. This patch increases the wait time before the new enumeration in order to allow the system to update the provided device list.
Differential Revision: https://phabricator.services.mozilla.com/D17843
--HG--
extra : moz-landing-system : lando