This patch won't actually build, because a few bits of code are used
for both nsIFactory::createInstance and static components, and static
components are not fixed until the next patch.
The first place is nsLoadGroupConstructor, which uses an nsIFactory
macro to create a static component constructor. (This could be worked
around by expanding the macro to the state before this patch.)
The other issue is that nsAppShellConstructor is used in an nsIFactory
on OSX, but as a static component on all other platforms. This could
be worked around by wrapping nsAppShellConstructor in an adaptor that
passes in the extra null argument to nsAppShellConstructor.
Differential Revision: https://phabricator.services.mozilla.com/D146456
nsIFactory is binary compatible with Windows COM's IClassFactory,
but nothing seems to depend on it. This patch removes the test
for compatibility, TestCOM, and removes the lockFactory
method that isn't otherwise needed.
Differential Revision: https://phabricator.services.mozilla.com/D146386
This was failing on Linux only. I thought maybe we were hitting the title bar and so weren't seeing the events so tried moving the events further into the window and it started working.
Depends on D146160
Differential Revision: https://phabricator.services.mozilla.com/D146161
The bulk of the changes are to make the sending of events much more similar to how widget/tests/browser/browser_test_swipe_gesture.js works (because that is a test that is currently working well).
browser_test_swipe_gesture.js opens a tab and uses tab.linkedBrowser to target the events. This makes sense because when we add the event listeners here https://searchfox.org/mozilla-central/rev/b72e9d7d63bf499d1d8168291b93d4ec7fde236e/browser/base/content/browser-gestureSupport.js#49 we add them to the tabbox.
We create synthesizeSimpleGestureEvent in apz_test_native_event_utils.js so we can target other elements (rather than widget relative coords) more easily. This makes several functions async so we propagate that through.
We also change the coords from 0,0 to 10,10 to make sure it's within the bounds of the tabbox event listener (not sure if this is necessary or not, I didn't test without this).
And then I ran eslint on the file. That's should cover everything, hopefully that explanation makes review relatively easy.
Differential Revision: https://phabricator.services.mozilla.com/D146160
Startup performance tests are browser-chrome tests which use Marionette
to install required extensions. Because Marionette will be initialized
earlier during the startup of Firefox this can cause a partially updated
remote control cue for the first opened browser window.
As such stop updating the remote control cue by guarding this behavior
behind two flags - when the browser is in automation and a special
preference set.
Depends on D145933
Differential Revision: https://phabricator.services.mozilla.com/D145934
Startup performance tests are browser-chrome tests which use Marionette
to install required extensions. Because Marionette will be initialized
earlier during the startup of Firefox this can cause a partially updated
remote control cue for the first opened browser window.
As such stop updating the remote control cue by guarding this behavior
behind two flags - when the browser is in automation and a special
preference set.
Differential Revision: https://phabricator.services.mozilla.com/D145934
There's nobody working on it, and tooltips should hopefully be nice
enough after recent changes (bug 1765423).
Having it enabled causes artifacts like bug 1767815 comment 3. We can
always rescue this from hg history if needed.
Differential Revision: https://phabricator.services.mozilla.com/D145621
In case of multiple subdomains without an own cookie permission we need to be able to check the cookie permission
of the domain those subdomains get their permissions from multiple times,
so we can not remove it after the first subdomain.
Differential Revision: https://phabricator.services.mozilla.com/D144573
* Sketch in recently-closed-tabs section and listing
* Add some styles and suggested markup for the page-level sections & headers
Differential Revision: https://phabricator.services.mozilla.com/D143365
When downloading a file, we check for existing mime types and construct
a new one if it's unrecognized. Mime types have a flag,
alwaysAskBeforeHandling, that determines whether the unknown content
type dialog should be opened before handling the file. Before bug
1733492, the default value for that flag was simply true. Since the new
downloads flow is intended to avoid unnecessary steps, the default value
was changed to the inverted value of the new downloads panel
improvements pref. This patch adds a new pref that the mime info
constructor will read in configuring the flag's value. If the
improvements pref is not enabled, then the flag will be true, so the UCT
dialog will open. If the improvements pref is enabled, then it'll use
the value of the new pref. Also add a an interface for the pref to the
about:preferences UI, and automatically migrate a false value for
browser.download.improvements_to_download_panel to a true value for this
pref. I'm updating some tangentially related test files since they
happen to be touched slightly by this change. Strictly speaking they
would still work, but if the pref value was somehow changed from the
default they would fail.
Differential Revision: https://phabricator.services.mozilla.com/D143002
