I need to use these from Rust to insert mapped attribute names in the
bloom filter, and this would save me handrolling even more bindings :)
Differential Revision: https://phabricator.services.mozilla.com/D111731
If we double tap on an element that is narrower than the viewport at maximum we can get into a situation where we zoom on part (say the bottom half) of that element but we could easily fit the entire element.
This happens because the code that calculate the rect to zoom to (CalculateRectToZoomTo) doesn't know about the maximum zoom. So it proceeds as though we will fit the width of the element. Under that assumption we will have to cut off part of the element vertically, so the code centers the rect on the users tap point.
This ends up cutting off part of the element vertically when it is clear that the whole element can fit on screen, which is a pretty ugly result.
This is not my favourite patch. This seemed to make the most sense. Another option I considered was passing the tap point through to AsyncPanZoomController::ZoomToRect but I think this approach came out better: the calculation all happens in one place at one time.
Differential Revision: https://phabricator.services.mozilla.com/D110538
Actually, we disable all mochitests in dom/events on GeckoView now.
We should run mochitests even if on GeckoView if it is passed.
Differential Revision: https://phabricator.services.mozilla.com/D111607
The priority manager tracks which browser parents are active in each process,
so it needs to be told when a browser parent is no longer active. This
is currently implemented by observing ipc:browser-destroyed, which happens
in BrowserHost::DestroyComplete().
However, with Fission, not all BrowserParents are held by BrowserHosts. I
don't think this is an issue right now, but if the priority manager is going
to properly prioritize processes due to the presence of active non-top-level
frames, then it needs to also deprioritize them when they go away.
This patch deals with this situation by directly telling the priority
manager that the browser parent is becoming inactive via the existing
ActivityChanged method, in the BrowserParent::Deactivated() method,
which is called when a browser parent is being destroyed or entering
the BF cache. I think it makes sense in both cases that we no longer
want to prioritize the process that the page is in.
This does mean that we are telling the priority manager about more
ContentParents which is potentially more expensive, but the old code
also ended up doing a hashtable remove in every single
ParticularProcessPriorityManager, whereas the new code only does it
for one, so hopefully it is a net win overall.
(The reason for this is that in ParticularProcessPriorityManager's
OnBrowserParentDestroyed() method the browserHost->GetContentParent()
check will always return null because the browser host nulls out
mRoot immediately before it does ipc:browser-destroyed, so the hash
table remove is never skipped.)
This patch also removes the last thing that ParticularProcessPriorityManager
was observing, so it no longer needs to be an nsIObserver.
Differential Revision: https://phabricator.services.mozilla.com/D111654
As of the next patch, it won't be used just for indicating the
activity of an entire tab, so let's rename it.
Also alphabetize the order of some forward declarations.
Differential Revision: https://phabricator.services.mozilla.com/D111701
ParticularProcessPriorityManager observes remote-browser-shown and recomputes
the priority for the given browser. This patch eliminates the observer call
and instead makes the frame loader do a direct call.
I think doing it this way is a little clearer, and also the next patch will
eliminate the other reason ParticularProcessPriorityManager is an observer,
which will let us not not register something as an observer for every content
process, which I think is also good.
There should be no change in behavior.
Differential Revision: https://phabricator.services.mozilla.com/D111653
This I'm not 100% sure. Should be harmless, but it's a bit subtle.
Maybe we should special-case it with "we're at the beginning of the
pattern"? Reasoning below:
The previous patch restores the performance of the original test-case.
However, if you go to the reduced test-case and try to type " re" in the
findbar, we still take a long time. The reason for that is not that the
previous patch is not effective, but that the findbar sends find
requests as soon as you type, and thus we end up with a request to find
" ", which matches a gazillion spaces in the page and causes us to use
tons of memory and time. Finding " re" is actually super-fast :-)
This fixes it, but it is a bit subtle, so thoughts? Perhaps the findbar
should wait a bit to perform the search before sending a query for " "
instead or something? But I'd rather make it fast.
Differential Revision: https://phabricator.services.mozilla.com/D111634
This expands on existing checks when getting a webms buffered intervals. The
additional check ensures we don't end up with end < start due to our code that
clamps end at duration.
This patch moves those checks into their own helper function so as to reduce
clutter in GetBuffered.
Differential Revision: https://phabricator.services.mozilla.com/D111152
Olli Pettay
Alexandru Michis
Claudia
Christoph Kerschbaumer
Markus Stange
Mike Conley
Eden Chuang
Edgar Chen
Noemi Erli
Kershaw Chang
Martin Giger
Niklas Goegge
Emilio Cobos Álvarez
Timothy Nikkel
Makoto Kato
alwu
Karl Tomlinson
Andrew McCreight
Butkovits Atila
Kagami Sascha Rosylight
Bryce Seager van Dyk
Tom Schuster
stransky