Make it return a margin from client area to window area, and add an
explicit function to get the size difference.
No behavior change.
Depends on D166428
Differential Revision: https://phabricator.services.mozilla.com/D166431
This method always returned GetMainThreadSerialEventTarget(). This patch
switches all callers over to use that method instead.
We can't easily switch all calls to be calls to NS_GetMainThread(), as there is
no version of that method returning a bare nsIThread* instance.
I didn't introduce one, as we may want to add a lock around mMainThread in the
future, which would require removing nsThreadManager::GetMainThreadWeak. As
this method only returns nsISerialEventTarget, it method could remain
implemented, however, by returning a statically allocated fake event target
which forwards dispatches (and QIs to nsIThread) to the real main thread.
Differential Revision: https://phabricator.services.mozilla.com/D166608
This only changes the behaviour when called with a TaskQueue or other type
using SerialEventTargetGuard on the stack. They are being switched over as the
existing GetCurrentEventTarget method is being removed, as it is somewhat
confusing, and poorly documented.
Callers which need to get the current thread even when on a threadpool or
behind a TaskQueue were switched to GetCurrentEventTarget in the previous part.
Differential Revision: https://phabricator.services.mozilla.com/D166607
These callers are depending on the existing behaviour which always returns a
thread, and does not respect custom TaskQueues. In the next part, all remaining
callers will be switched to GetCurrentSerialEventTarget.
Differential Revision: https://phabricator.services.mozilla.com/D166606
We aren't likely to try to make these changes any time soon, so cleaning out
these unnecessary methods which just return `this` will simplify things.
I was unable to find any calls to the `.eventTarget` getter in JS, which makes
sense, as the nsIThread type is only really used in JS as a wrapper around the
main thread in older code. Because of that, it has been removed as well.
Differential Revision: https://phabricator.services.mozilla.com/D166605
This will help catch issues such as the one from bug 1806751, as we will assert
earlier in the process. This also aligns better with the existing documentation
of the method (which has been updated), which suggests that the method would
assert if called on a thread pool.
Differential Revision: https://phabricator.services.mozilla.com/D166604
This was always being tracked internlly to implement
nsThreadPool::IsOnCurrentThread, however this patch exposes the getter
publicly.
This will be used to assert if GetCurrentSerialEventTarget() is called from a
threadpool thread without a TaskQueue in the next part.
Differential Revision: https://phabricator.services.mozilla.com/D166603
I wrote this while debugging / fixing bug 1806438, and this is kind of
related and needed to fix that bug in one of my machines.
This ensures that all size mode changes go through a central place.
In order to do that, we need to pass whether we need to ShowWindow()
since doing it redundantly in some cases like windows-triggered sizemode
changes would break stuff.
Differential Revision: https://phabricator.services.mozilla.com/D166254
This is a very old and legacy attribute which always had a fuzzy definition.
As of today it was a somewhat alias of "not debugging a local/remote tab".
Differential Revision: https://phabricator.services.mozilla.com/D166904
Ideally, the debugging context should rather be defined by the descriptor
rather than the top target.
On top of that isAddon is only an alias for isWebExtension.
So drop most usages of isAddon and otherwise use isWebExtension.
Differential Revision: https://phabricator.services.mozilla.com/D166903
Originally, we determine whether to show doorhanger by checking if users
have modified autofilled fields. If yes, then we show the credit card update doorhanger.
However, this is not always correct. It is possible the updated data
matches other data in the storage, in that case, we still shouldn't show
the update doorhanger.
This patch updates the behavior to always compare the submmited data and
data in the storage to determine whether to show the update doorhanger.
Differential Revision: https://phabricator.services.mozilla.com/D166316
I wrote this while debugging / fixing bug 1806438, and this is kind of
related and needed to fix that bug in one of my machines.
This ensures that all size mode changes go through a central place.
In order to do that, we need to pass whether we need to ShowWindow()
since doing it redundantly in some cases like windows-triggered sizemode
changes would break stuff.
Differential Revision: https://phabricator.services.mozilla.com/D166254
* Use enumerate(...) instead of manual indexing
* It's safe to modify a list we're iterating on as long as we break out
of the iteration right after the modification.
Differential Revision: https://phabricator.services.mozilla.com/D165053
Basic loop invariant code motion. The impact on execution time is not
totally negligible due to the number of tests involved.
Differential Revision: https://phabricator.services.mozilla.com/D165052
This module defines a single, efficient function to deepcopy a task. It
is faster than deepcopy because it doesn't need to track cycles and
duplicate references that don't make sense for tree (and not graph)
structures.
I measure a speedup > 10% on mach taskgraph tasks --fast >/dev/null.
Differential Revision: https://phabricator.services.mozilla.com/D164789
For example, given that
`surface_rect`: `Box2D((0.0, -1.04904175e-5), (588.99994, 0.0))`
`surface bound`: Box2D((0.0, -512.0), (1024.0, 0.0))
Then doing round_out() after translating the surface_rect with
`-surface_bounds.min.to_vector()` results an empty rect.
We need to make sure that negative origin `surface_rect` is not collapssed.
Differential Revision: https://phabricator.services.mozilla.com/D166887
This patch receives a weather icon id from our merino server. We then use that
icon id and map it to a specific weather icon svg file within
urlbar-dyanmic-result.css. The icons colors are specified for light, dark, and
high contrast mode.
Differential Revision: https://phabricator.services.mozilla.com/D166848
This changes the behavior in a few ways:
- the 'active' notification is now only fired when a new user event has been received by Firefox, rather than by any application on the entire system.
- the 'active' notification will fire immediately when Firefox receives a new event. Before the patch is was fired within 5s of the user returning on some plateforms (eg. Mac) and immediately on some other platforms that already called ResetIdleTimeout (windows, gtk, android). I'm not sure if these existing calls to ResetIdleTimeout are really needed, nor if they add significant overhead.
- when an idle observer has been notified of 'idle', it won't be notified again until Firefox receives events. Before the patch, if the user used other applications while Firefox was in the background, we would keep sending active and idle notifications to our idle observers. This behavior was probably initially intended when the nsUserIdleService was introduced to support the use case of instant messaging clients, but doesn't seem to match the expectations of the existing consumers of the service.
Differential Revision: https://phabricator.services.mozilla.com/D166306
The legacy listener was explicitely avoiding emitting this event for non top-level targets.
It seems like all frontend code listening to will-navigate ignore the event is targetFront.isTopLevel is false,
so it looks like no code would expect these event.
So let's try to avoid emitting them if they aren't used by anyone.
(and can be confusing/buggy in the context of the browser toolbox)
Differential Revision: https://phabricator.services.mozilla.com/D166769
For normal (desktop) fission, we add NotifyImpendingShutdown before we notify destroy to the browser if we know a content process will go away both during normal operations and when the parent shuts down.
For e10s and Android we can only add NotifyImpendingShutdown when the parent process is shutting down, as they use a different keep alive logic that is hard to anticipate.
Differential Revision: https://phabricator.services.mozilla.com/D166303
Two notable things here:
- Small refactor of AttributionCode.jsm to make it more testable (allowing `getCampaignId` to be easily stubbed out)
- An ugly skip of one of the "invalid" attribution code tests -- for reasons noted in the comments. Ultimately, this points to maybe a refactor or larger change being needed, but I don't think it's worth blocking getting these tests on.
Differential Revision: https://phabricator.services.mozilla.com/D166688
After adding some assertions to GetCurrentSerialEventTarget and running tests,
I was able to find this caller which could lead to the crashes here. By running
database maintenance on a TaskQueue the captured event target will be one which
accepts and processes dispatches.
Differential Revision: https://phabricator.services.mozilla.com/D166609
Emilio Cobos Álvarez
Nika Layzell
Mark Banner
Cosmin Sabou
Mike Conley
Alexandre Poirot
Sandor Molnar
Dimi
Mark Striemer
Gijs Kruitbosch
Adam Vandolder
Geoff Brown
Mike Hommey
serge-sans-paille
Hiroyuki Ikezoe
stransky
Jonatan Klemets
mcheang
Glenn Watson
Florian Quèze
Julian Descottes
Edgar Chen
Jens Stutte
Ben Hearsum
Dave Townsend
Andreas Farre
Chris H-C