Use MediaControlService's context when creating the notification in order to
prevent a NPE.
Differential Revision: https://phabricator.services.mozilla.com/D17391
--HG--
extra : moz-landing-system : lando
This starts porting other tests to work with QuantumBar and starts expanding UrlbarTestUtils.jsm with more helper functions.
For the tests, I'm generally using replacing with UrlbarTestUtils except for promiseAutocompleteResultPopup/promiseSearchComplete. These functions feel like they need a more in-depth change (bug 1522902), but probably not until we can remove the old bar.
browser_autocomplete_a11y_label.js and browser_autocomplete_autoselect.js are partially ported, but won't run on QuantumBar yet due to missing functionality.
Depends on D18262
Differential Revision: https://phabricator.services.mozilla.com/D18338
--HG--
rename : browser/components/urlbar/tests/legacy/browser_action_searchengine.js => browser/components/urlbar/tests/browser/browser_action_searchengine.js
rename : browser/components/urlbar/tests/legacy/browser_action_searchengine_alias.js => browser/components/urlbar/tests/browser/browser_action_searchengine_alias.js
rename : browser/components/urlbar/tests/legacy/browser_autocomplete_edit_completed.js => browser/components/urlbar/tests/browser/browser_autocomplete_edit_completed.js
rename : browser/components/urlbar/tests/legacy/browser_new_tab_urlbar_reset.js => browser/components/urlbar/tests/browser/browser_new_tab_urlbar_reset.js
rename : browser/components/urlbar/tests/legacy/browser_urlbar_remove_match.js => browser/components/urlbar/tests/browser/browser_urlbar_remove_match.js
extra : moz-landing-system : lando
When hardware acceleration is enabled, GLContextGLX::FindVisual() is used to choose visual. When widget does not request AlphaVisual, the FindVisual() always choose RGB(24bit) visual. It causes to loose alpha during readback.
Differential Revision: https://phabricator.services.mozilla.com/D18179
--HG--
extra : moz-landing-system : lando
I am not a huge fan of the UnwrapReflectorToISupports setup here. Maybe we
should introduce two differently-named methods that make it somewhat clear what
the limitations of not taking a JSContext are? I couldn't think of sane
naming...
Differential Revision: https://phabricator.services.mozilla.com/D17885
--HG--
extra : moz-landing-system : lando
The basic idea for the changes around UnwrapObjectInternal and its callers
(UnwrapObject, UNWRAP_OBJECT, etc) is to add a parameter to the guts of the
object-unwrapping code in bindings which can be either a JSContext* or nullptr
(statically typed). Then we test which type it is and do either a
CheckedUnwrapDynamic or CheckedUnwrapStatic. Since the type is known at
compile time, there is no actual runtime check; the compiler just emits a call
to the right thing directly (verified by examining the assembly output on
Linux).
The rest of the changes are mostly propagating through that template parameter,
adding static asserts to make sure people don't accidentally pass nullptr while
trying to unwrap to a type that might be a WindowProxy or Location, etc.
There are also some changes to places that were calling CheckedUnwrap directly
to use either the static or dynamic version, as needed.
Differential Revision: https://phabricator.services.mozilla.com/D17883
--HG--
extra : moz-landing-system : lando
This will allow us to correctly handle CheckedUnwrapDynamic on wrappers around
WindowProxy and Location.
Differential Revision: https://phabricator.services.mozilla.com/D17882
--HG--
extra : moz-landing-system : lando
We're going to need this because we will have multiple Realms in the same
compartment which want different CheckedUnwrap behavior in some cases. So we
need to be able to check which Realm we're in.
Differential Revision: https://phabricator.services.mozilla.com/D17881
--HG--
extra : moz-landing-system : lando
This is another very specific issue.
If you have `<img name="attributes"/>` in the dom then `document.attributes` will return the `<img>` tag.
In the source we bail if `!this.rawNode.attributes` but if we are on the document node this returns the image tag. Because the image tag is not a `NamedNodeMap` trying to iterate over the tag throws the error.
There is a test file [here](https://bugzilla.mozilla.org/attachment.cgi?id=9040577).
Differential Revision: https://phabricator.services.mozilla.com/D18340
--HG--
extra : moz-landing-system : lando
This includes some assorted fixes from upstream plus an adaptation of the
patch in b988fa74ec18de6214b18f723e48331d9a7802ae which includes heap memory
regions in the minidump. Since our support for that is more extensive than
upstream breakpad the resulting change reflects this. Last but not least the
fixes for bug 1489094 and bug 1511140 were split out as patches to be applied
to the unmodified breakpad sources. They will be reintegrated as soon as we
fork breakpad for good.
Differential Revision: https://phabricator.services.mozilla.com/D16326
--HG--
extra : moz-landing-system : lando
Passing in --exact reverses the behaviour of the ' operator. For example,
take the query "foo 'bar".
By default: foo is a fuzzy match and bar is an exact match.
With --exact: foo is an exact match and bar is a fuzzy match
Differential Revision: https://phabricator.services.mozilla.com/D16734
--HG--
extra : moz-landing-system : lando
This patch also makes a couple of changes related to clipping:
- The composition bounds clip is applied to the async zoom container but
not its contents.
- The clip applied to the async zoom container is not divided by the
resolution. This clip is applied after the resolution, so dividing
by the resolution clips content away when zoomed in.
Differential Revision: https://phabricator.services.mozilla.com/D17176
--HG--
extra : moz-landing-system : lando
I didn't use the checkPromptModal function because the implementation in chromeScript was getting a null document reference. Since handlePrompt already has access to this information it made sense to extend handlePrompt to cover more cases.
Differential Revision: https://phabricator.services.mozilla.com/D18267
--HG--
rename : toolkit/components/passwordmgr/test/test_xhr.html => toolkit/components/passwordmgr/test/mochitest/test_xhr.html
extra : moz-landing-system : lando
Eventually this op could use an IC or some frontend/bytecode refactoring to make
it faster in the interpreter. For now following the C++ interpreter is the
simplest solution though.
Differential Revision: https://phabricator.services.mozilla.com/D17939
--HG--
extra : moz-landing-system : lando
This is just a VM call in the interpreter. We could optimize this with an IC or
inline path if it ever becomes a problem.
Depends on D17934
Differential Revision: https://phabricator.services.mozilla.com/D17935
--HG--
extra : moz-landing-system : lando
This adds js::SingletonObjectLiteralOperation and calls it from both the
interpreter and Baseline. The Baseline compiler still has a fast path for the
cloning-not-necessary case.
Depends on D17645
Differential Revision: https://phabricator.services.mozilla.com/D17934
--HG--
extra : moz-landing-system : lando
