In pdf.js, files are saved thanks to a blob but the original URL is lost.
Consequently, the download panel doesn't contain any information about the
origins of a saved pdf.
The saveURL, internalSave and nsITransfer.init functions has now a parameter for this originalURL.
Differential Revision: https://phabricator.services.mozilla.com/D147651
Instead of exporting lazy getter, export a function that returns the FxAccount
singleton, lazily creating on the first call, and define the lazy getter on the
consumer side that calls the function.
Differential Revision: https://phabricator.services.mozilla.com/D147634
This is the most minimal fix for the bug. The issue is basically that
XUL <tree>s have a non-anonymous scrollbar that doesn't match the rule
above the one I'm modifying (which resets scrollbar directionality to
ltr).
Its _anonymous_ kids would inherit this rtl directionality and cache it,
and the wrong directionality would be used for actual anonymous
scrollbars, causing havoc later on due to the nsGfxScrollFrame reflow
callbacks.
This is wrong, anyways, there's no reason for inheriting the
directionality of the scrollbar to begin with.
Differential Revision: https://phabricator.services.mozilla.com/D147687
Instead of exporting lazy getter, export a function that returns the FxAccount
singleton, lazily creating on the first call, and define the lazy getter on the
consumer side that calls the function.
Differential Revision: https://phabricator.services.mozilla.com/D147634
I noticed that the current implementation is very short and easy to miss. Chrome is much longer. I tweaked it to what felt pretty good.
Although this seems like only an increase from 0.25s to 0.35s it's actually much longer than that because the cubic-bezier curve (viewable at https://cubic-bezier.com/#.07,.95,0,1 ) goes to zero almost immediately. The new curve (viewable at https://cubic-bezier.com/#.25,.1,.25,1 ) is closer to linear with an ease-in and an ease-out.
Differential Revision: https://phabricator.services.mozilla.com/D142818
We can get into a state where box.style.opacity = 1 but that hasn't been flushed to the style system yet, the style system thinks the value is 0, so when we set box.style.opacity = 0 later it won't cause any transition to start and transitionend will never happen and the ui element will never been shown with non-zero opacity.
We use getComputedStyle to flush the value to the style system, this has two positive effects. It means we will show the ui element with non-zero opacity as well as making sure the transition will happen and transitionend will be called.
I think getComputedStyle should only flush in the relevant subtree (two elements total) so this should be fine.
Differential Revision: https://phabricator.services.mozilla.com/D142822
When the tracking protection toast popup closes on a timer, it doesn't
smoothly fade out, because it uses PanelMultiView.hidePopup instead of
panelNode.hidePopup. The static method on PanelMultiView ultimately
calls panelNode.hidePopup, but it doesn't have a parameter for enabling
the animation so it passes nothing to that method. This patch extends
PanelMultiView's hidePopup class methods to add an optional `animate`
parameter, and adds that parameter to the toast popup's hidePopup call.
This should slightly reduce the speed of part of
browser_protectionsUI.js but I don't think it affects any other tests.
Differential Revision: https://phabricator.services.mozilla.com/D146394
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
In addition to adding async/await, I also added early return statements
when we know initialization is occuring again, or if there is evidence
that it has been uninitialized.
A concrete example of this would be from the Library, where clicking on
on a folder/category on the left will run initPanel at the same time as
the highlighted folder/bookmark on the right changes (also runs initPanel).
Differential Revision: https://phabricator.services.mozilla.com/D141800
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
