webidlsrcs.mk is treated specially by the build system, and this entire
process should be supported better by moz.build, but in the meantime this
fixes the clobber bug caused by not re-building these targets when defines
are updated.
Differential Revision: https://phabricator.services.mozilla.com/D33415
--HG--
extra : moz-landing-system : lando
This is done by sending a message over PBrowser and PBrowserBridge when the
event would fire to fire it in the correct process.
Differential Revision: https://phabricator.services.mozilla.com/D33083
--HG--
extra : moz-landing-system : lando
This is the more logical behaviour than the previous, where an unknown process
would be given the full "dom.ipc.processCount" process limit, which could lead
to unintentionally allocating a large # of processes.
Differential Revision: https://phabricator.services.mozilla.com/D32763
--HG--
extra : moz-landing-system : lando
This allows the # of processes to be specified for remote types like
"webIsolated", used by fission windows.
Differential Revision: https://phabricator.services.mozilla.com/D32762
--HG--
extra : moz-landing-system : lando
Right now there's some duplicated code with the focus manager and the
DOMWindowFocus event.
Android didn't handle the new framefocusrequested event, so the test-cases in
bug 416771 still didn't work there.
I think using the focus manager codepath everywhere is preferable. I confirmed
manually that the stuff that sent DOMWindowFocus events still works as expected
with this patch (i.e., switching to the right tab when you click on a
notification, etc.).
This fixes it so that it works in Fennec, and it sends the focus events right in
GeckoView Example (i.e., we get here[1] properly).
The snippet that Snorp provided on IRC to implement the "bring activity to
front" stuff (`startActivity(getIntent())`) didn't actually work for me, but I
confirmed that the right message is sent when the focus is requested, and that
we get there.
[1]: https://searchfox.org/mozilla-central/rev/952521e6164ddffa3f34bc8cfa5a81afc5b859c4/mobile/android/geckoview_example/src/main/java/org/mozilla/geckoview_example/GeckoViewActivity.java#503
Depends on D32353
Differential Revision: https://phabricator.services.mozilla.com/D32354
--HG--
extra : moz-landing-system : lando
This pref toggled gives me the desired behavior on Linux, and it should be
trivial to revert to the previous behavior if needed.
Depends on D33393
Differential Revision: https://phabricator.services.mozilla.com/D33394
--HG--
extra : moz-landing-system : lando
It's only moved around, but not actually used anywhere.
I have no idea what this was supposed to control in the past but it doesn't seem
useful to keep it around.
Differential Revision: https://phabricator.services.mozilla.com/D33393
--HG--
extra : moz-landing-system : lando
Remove a few no-longer-necessary `AllowCompilerWarnings()` before anything that depends upon them sneaks in.
Differential Revision: https://phabricator.services.mozilla.com/D33631
--HG--
extra : moz-landing-system : lando
Currently, BrowserChild rendering is enabled and disabled by `RecvRenderLayers`, and this
method is called only by the tab switching code.
This commit does several things.
1. It factors out the code to enable/disable rendering to MakeVisible/MakeHidden so it can
be used outside of `RecvRenderLayers`
2. We track the current value of RenderLayers and use it in conjunction with EffectsInfo to
determine if we need to be rendering at any given moment
3. We only apply RenderLayers to the root OOP browser (not OOP-iframes)
These changes together make it so that BrowserChild will render IFF 'visible' || 'renderLayers',
and will only apply 'renderLayers' to the root browser.
Differential Revision: https://phabricator.services.mozilla.com/D31473
--HG--
extra : rebase_source : 12ad66f514cf1217899af42ca3891fe7b3f897dc
extra : intermediate-source : 3cb9ddccccf320b19f0deae88cd990982b703022
extra : source : e2197dd98aaeeb3d80b65c9892a82d41c4adc80d
The root PBrowser actor needs special case visibility behavior to satisfy the async tab
switcher. This commit adds a flag to track whether a BrowserChild is part of the root
actor.
Differential Revision: https://phabricator.services.mozilla.com/D33046
--HG--
extra : rebase_source : 5f7cb11f77d41f3265d211e99713a1dad6ae2579
extra : intermediate-source : 49e4d0e4fc7ccfa7b2c58bb9b64534c2d569a881
extra : source : adcc870662770a99962e721bd3c5ff4c2616c21d
This commit adds RemoteBrowser::UpdateEffects for updating a remote browser's
EffectsInfo over IPC.
A following commit will actually use the EffectsInfo for
enabling/disabling rendering for a remote browser, and another
commit will actually use these IPDL methods.
Differential Revision: https://phabricator.services.mozilla.com/D31472
--HG--
extra : rebase_source : 304d843d2c4a35f468aa847ee66005a932bb7eb2
extra : intermediate-source : d31b7d33efc711fb8115663f4cfc5bc98fd58d73
extra : source : 5aea122dea2120efe107c639b17678e0464b1389
This commits adds EffectsInfo for tracking graphical effects
that are applied to a remote browser's ancestors.
Differential Revision: https://phabricator.services.mozilla.com/D31471
--HG--
extra : rebase_source : 5c4cda4019095dbd00aa3bca2edff0dbd16e5ca8
extra : intermediate-source : b4d5865e33079a36f535501293f8aaec8b6bcf64
extra : source : e8e3d2d76d860c76ee351c8b10ed488fdac2d9fc
This commit adds two small fixes to make the OOP-iframe code more robust.
The first fixes a crash during shutdown for a tab that has OOP-iframes. It's
possible for the BrowserBridgeParent's to be shutdown before the root
BrowserParent. In this case, SetOwnerElement will run for the root BrowserParent,
but the child BrowserBridgeParent's will not have BrowserParent actors.
The second hooks up the BrowserBridgeParent constructor to actually use
the result code of BrowserBridgeParent::Init.
Differential Revision: https://phabricator.services.mozilla.com/D31477
--HG--
extra : rebase_source : bbe098c5ce75bd0fd26682a3b98f9958df5a2fcf
extra : intermediate-source : 83576499bf77d37e31b5328c0117650e57a03447
extra : source : 8f865f1f199c3e74844559a89b0ff642905513bd
This makes some callers a bit less awkward by not having, for example, to read
from the parent node or not depending on whether Element::BindToTree has been
called already or not.
Differential Revision: https://phabricator.services.mozilla.com/D33368
--HG--
extra : moz-landing-system : lando
We want to ensure the RDM browser's outer window sizes are not affected as the page is zoomed in or out. In the context of RDM, the size of the browser window will be the same as the viewport so I believe it's safe to assume that the window's outer size will be equal to its inner size when the zoom level is set to 100%.
I found we can get this value by using the presentation context's `GetDeviceZullZoom` method and applying it to the inner sizes of the RDM viewport.
Differential Revision: https://phabricator.services.mozilla.com/D32778
--HG--
extra : moz-landing-system : lando
Only gtk returns failure ever, and nobody checks the result anyway.
Use an enum class so that it's clear from the caller what it means.
Differential Revision: https://phabricator.services.mozilla.com/D32353
--HG--
extra : moz-landing-system : lando
BindContext was going to have way more information at first, but then I realized
that most of the things I wanted to know were basically a flag away using the
parent node.
Still I think it's worth it, now experimenting with BindToTree will only mean
adding a field to a struct that's included from a couple cpp files, instead of a
massive pain.
I also think this is clearer, and doing this highlights quite a few
inconsistencies in our code which I've left untouched, but commented with
FIXMEs.
Steps are:
$ for file in $(rg 'nsresult BindToTree\(' | cut -d : -f 1 | sort | uniq); do sed -i 's#nsresult BindToTree(Document\* aDocument, nsIContent\* aParent,#nsresult BindToTree(BindContext\&, nsINode\& aParent)#g' $file; done
$ for file in $(rg 'nsresult BindToTree\(' | cut -d : -f 1 | sort | uniq); do sed -i 's# nsIContent\* aBindingParent) override#override#g' $file; done
$ for file in $(rg '::BindToTree\(' | cut -d : -f 1 | sort | uniq); do sed -i 's#::BindToTree(Document\* aDocument, nsIContent\* aParent,#::BindToTree(BindContext\& aContext, nsINode\& aParent)#g' $file; done
$ for file in $(rg '::BindToTree\(' | cut -d : -f 1 | sort | uniq); do sed -i 's#nsIContent\* aBindingParent)##g' $file; done
$ for file in $(rg '::BindToTree\(' | cut -d : -f 1 | sort | uniq); do sed -i 's#::BindToTree(aDocument, aParent, aBindingParent)#::BindToTree(aContext, aParent)#g' $file; done
$ ./mach clang-format
Then manual fixups.
Depends on D32948
Differential Revision: https://phabricator.services.mozilla.com/D32949
The removal of the second CSP check is fixing a regression introduced in bug
965637. See https://github.com/whatwg/html/issues/4651#issuecomment-495050351
for details. We may want to re-introduce that check depending on the outcome
of that issue, but if so we should do that only if the target document's
principal subsumes our triggering principal.
This commit will not allow bookmarklets to access subresources that
CSP blocks, but will at least allow them to run.
Differential Revision: https://phabricator.services.mozilla.com/D33047
--HG--
extra : moz-landing-system : lando
It appears that in some cases we can have the wrong value for the
WindowGlobalParent::DocumentURI. This patch adds another case in SetNewDocument
which should ideally catch the case where the Document is replaced while
preserving the inner window.
Differential Revision: https://phabricator.services.mozilla.com/D33081
--HG--
extra : moz-landing-system : lando
It turns out that the temporary fix for bug 1528690 might be the right way to
do. Based on the recent crash reports, the mResultCode for the Transaction
object wasn't an NS_OK and the crashing operation hasn't updated the failure to
that yet. So, the right way to do here is that we should abort the operation on
the connection thread.
Differential Revision: https://phabricator.services.mozilla.com/D32004
--HG--
extra : moz-landing-system : lando
The removal of the second CSP check is fixing a regression introduced in bug
965637. See https://github.com/whatwg/html/issues/4651#issuecomment-495050351
for details. We may want to re-introduce that check depending on the outcome
of that issue, but if so we should do that only if the target document's
principal subsumes our triggering principal.
This commit will not allow bookmarklets to access subresources that
CSP blocks, but will at least allow them to run.
Differential Revision: https://phabricator.services.mozilla.com/D33047
--HG--
extra : moz-landing-system : lando
I think this is a good change regardless of other discussion in bug 1552587. If
we decide to move `mColor` to the top-level of the struct that can be done
separately.
Differential Revision: https://phabricator.services.mozilla.com/D32726
--HG--
extra : moz-landing-system : lando
This is similar to this Chromium change:
https://codereview.chromium.org/1155353002
The editing spec doesn't mention editing non-HTML documents, and historically
this is only a feature that WebKit has supported. Supporting this feature
increases the attack surface of the browser without a clear benefit, so it
seems like a good idea to converge on this behaviour.
Differential Revision: https://phabricator.services.mozilla.com/D32913
--HG--
rename : testing/web-platform/tests/html/editing/editing-0/making-entire-documents-editable-the-designmode-idl-attribute/user-interaction-editing-designMode.html => testing/web-platform/tests/html/editing/editing-0/making-entire-documents-editable-the-designmode-idl-attribute/user-interaction-editing-designMode-xml.xml
extra : moz-landing-system : lando
It turns out the `BuildPath()` method will still be exposed by DOM
API via `getTotalLength()`. So we need to fallback to `GetComputedStyleNoFlush()`
to handle display:none problem, and if the element doesn't even belong
to a document, we further fallback to 0.
`BuildPath()` being affected also means `GetStrokeWidth()`, etc. will also
be indirectly exposed to DOM API in some obscure cases. Let's add a utility
to handle the fallback.
Differential Revision: https://phabricator.services.mozilla.com/D33247
--HG--
extra : moz-landing-system : lando
The `WebProgressChild` no longer sends a `matchedList` parameter in its JSON
messages to the `RemoteWebProgress`, so it will always be undefined and trigger
a `ReferenceError`.
Differential Revision: https://phabricator.services.mozilla.com/D33202
--HG--
extra : moz-landing-system : lando
The renaming of MediaWebspeechRecognitionEnable to
media_webspeech_recognition_enable is to follow the StaticPrefs convention,
because bindings are going to assume that convention.
Differential Revision: https://phabricator.services.mozilla.com/D32942
--HG--
extra : moz-landing-system : lando
Only gtk returns failure ever, and nobody checks the result anyway.
Use an enum class so that it's clear from the caller what it means.
Differential Revision: https://phabricator.services.mozilla.com/D32353
--HG--
extra : moz-landing-system : lando
This doesn't clean up as much as a whole, but it's a step in the right
direction. In particular, it allows us to start using simple bindings for:
* Filters
* Shapes and images, almost. Need to:
* Get rid of the complex -moz- gradient parsing (let
layout.css.simple-moz-gradient.enabled get to release).
* Counters, almost. Need to:
* Share the Attr representation with Gecko, by not using Option<>.
* Just another variant should be enough (ContentItem::{Attr,Prefixedattr},
maybe).
Which in turn allows us to remove a whole lot of bindings in followups to this.
The setup changes a bit. This also removes the double pointer I complained about
while reviewing the shared UA sheet patches. The old setup is:
```
SpecifiedUrl
* CssUrl
* Arc<CssUrlData>
* String
* UrlExtraData
* UrlValueSource
* Arc<CssUrlData>
* load id
* resolved uri
* CORS mode.
* ...
```
The new one removes the double reference to the url data via URLValue, and looks
like:
```
SpecifiedUrl
* CssUrl
* Arc<CssUrlData>
* String
* UrlExtraData
* CorsMode
* LoadData
* load id
* resolved URI
```
The LoadData is the only mutable bit that C++ can change, and is not used from
Rust. Ideally, in the future, we could just use rust-url to resolve the URL
after parsing or something, and make it all immutable. Maybe.
I've verified that this approach still works with the UA sheet patches (via the
LoadDataSource::Lazy).
The reordering of mWillChange is to avoid nsStyleDisplay from going over the
size limit. We want to split it up anyway in bug 1552587, but mBinding gains a
tag member, which means that we were having a bit of extra padding.
One thing I want to explore is to see if we can abuse rustc's non-zero
optimizations to predict the layout from C++, but that's something to explore at
some other point in time and with a lot of care and help from Michael (who sits
next to me and works on rustc ;)).
Differential Revision: https://phabricator.services.mozilla.com/D31742
This method wasn't correct for what mconley needed and is no longer needed.
Differential Revision: https://phabricator.services.mozilla.com/D31506
--HG--
extra : moz-landing-system : lando
Temporary solution until we get sanitized chrome JS stacks for the crash
reporter.
Differential Revision: https://phabricator.services.mozilla.com/D32933
--HG--
extra : moz-landing-system : lando
We do this because we will be introducing more privileged content processes
and we want to be able to distinguish them.
Differential Revision: https://phabricator.services.mozilla.com/D30274
--HG--
rename : browser/base/content/test/tabs/browser_new_tab_in_privileged_process_pref.js => browser/base/content/test/tabs/browser_new_tab_in_privilegedabout_process_pref.js
extra : moz-landing-system : lando
In general case, we set `IsHandlingUserInput` flag in `PresShell::EventHandler::HandleEventWithCurrentEventInfo()` for user interaction event.
However the interaction could happen on parent process, like e10s select and input date etc., whose dropdown/popup menu is implemented on parent process and it sends the interaction result to content process, then generates/dispatches corresponding event on content process directly. For such case, we need an addition hook before calling the event listener, just like what we do for popup blocker. It also makes more sense that we handle `popup blocker state` and `IsHandlingUserInput` flag at a consistent time.
Differential Revision: https://phabricator.services.mozilla.com/D32020
--HG--
extra : moz-landing-system : lando
PresShell::EventHandler::HandleEventWithCurrentEventInfo is the only possible
place will do such handling; other places pass either a nullptr or a
non-MouseDown/Up event.
Differential Revision: https://phabricator.services.mozilla.com/D32431
--HG--
extra : moz-landing-system : lando
For iframes in a different process to their embedder, when the embedded iframe content process tells the parent process about the iframe document, it does not have the actor for the parent document accessible, nor does it know the accessible id of the embedding iframe.
However, the embedder will have previously sendt the actor and id for the embedder accessible to the parent via PBrowserBridge, so we can use that to identify the parent accessible.
Differential Revision: https://phabricator.services.mozilla.com/D31395
--HG--
extra : moz-landing-system : lando
We do this because we will be introducing more privileged content processes
and we want to be able to distinguish them.
Differential Revision: https://phabricator.services.mozilla.com/D30274
--HG--
rename : browser/base/content/test/tabs/browser_new_tab_in_privileged_process_pref.js => browser/base/content/test/tabs/browser_new_tab_in_privilegedabout_process_pref.js
extra : moz-landing-system : lando
The only protocol that can't be created off the main thread at the moment is
moz-extension, and that can be handled at a later time.
Differential Revision: https://phabricator.services.mozilla.com/D30713
--HG--
extra : moz-landing-system : lando
Supporting out-of-process iframes requires us to hold onto a DocAccessibleParent in BrowserBridgeParent.
However, we can't guarantee the order of cleanup between the two content processes.
Therefore, we need reference counting to kee the object alive.
Differential Revision: https://phabricator.services.mozilla.com/D32277
--HG--
extra : moz-landing-system : lando
$ for file in $(rg UnbindFromTree | cut -d : -f 1 | sort | uniq); do sed -i 's#UnbindFromTree(bool aDeep = true,#UnbindFromTree(#g' $file; done
$ for file in $(rg UnbindFromTree | cut -d : -f 1 | sort | uniq); do sed -i 's#UnbindFromTree(bool aDeep,#UnbindFromTree(#g' $file; done
$ for file in $(rg UnbindFromTree | cut -d : -f 1 | sort | uniq); do sed -i 's#UnbindFromTree(aDeep,#UnbindFromTree(#g' $file; done
$ ./mach clang-format
And fix the two callers and little use of the aDeep argument (see the "Manual
changes" patch attached to bug).
Differential Revision: https://phabricator.services.mozilla.com/D32898
--HG--
extra : moz-landing-system : lando
Chris Manchester
shindli
Nika Layzell
Emilio Cobos Álvarez
Cosmin Sabou
Tom Tung
Henri Sivonen
Shashank kaushik
Christoph Kerschbaumer
Andrea Marchesini
Edgar Chen
Zibi Braniecki
Ehsan Akhgari
Jonathan Kingston
Neil Deakin
Jeff Gilbert
Boris Zbarsky
Jan de Mooij
David Major
Ryan Hunt
Dorel Luca
Martin Stransky
Cameron McCormack
Micah Tigley
Mark Striemer
Honza Bambas
Sebastian Hengst
Jon Coppeard
Razvan Maries
Johann Hofmann
violet
John Dai
Csoregi Natalia
Daniel Varga
arthur.iakab
Andreas Pehrson
Jan Varga
Narcis Beleuzu
Ting-Yu Lin
Barret Rennie
Dan Minor
prathiksha
James Teh
Daosheng Mu
Brindusan Cristian
Byron Campen [:bwc]
Brendan Dahl
Tom Ritter
Frederik Braun
Brian Hackett
Noemi Erli
Oana Pop Rus
Valentin Gosu
Perry Jiang
Matthew Gregan