This also updates layoutdebug.js, which in some ways pretends to be like a browser window but
is its own special snowflake. I kept the method naming conventions similar to the main
browser window.
Depends on D168394
Differential Revision: https://phabricator.services.mozilla.com/D168395
This also updates layoutdebug.js, which in some ways pretends to be like a browser window but
is its own special snowflake. I kept the method naming conventions similar to the main
browser window.
Depends on D168394
Differential Revision: https://phabricator.services.mozilla.com/D168395
Move it to the mozilla::widget namespace.
Use enum classes for transparency, popup type, popup level, etc.
Mostly automated with sed, but there were a few manual changes required
as well in windows code because they relied on Atomic<TransparencyMode>
working (which now doesn't because TransparencyMode is 1 byte instead of
4 bytes).
Differential Revision: https://phabricator.services.mozilla.com/D167537
Right now we rely on the menulist to be injected by hand in all the
relevant windows. Instead create it lazily, making the select code more
standalone.
The DevTools window was missing it, for example.
Differential Revision: https://phabricator.services.mozilla.com/D149620
Make popup browsers non-transparent so that we can get a meaningful
canvas background-color from layout. I don't think it matters since
popups are not meaningfully transparent since bug 1449933.
Depends on D133772
Differential Revision: https://phabricator.services.mozilla.com/D133773
These events are fired for all parent process documents by the code that
handles native mousewheel events. This change adds listeners to those events
and handles them similarly to how they are handled for browsers.
Differential Revision: https://phabricator.services.mozilla.com/D87113
The functionality has been fully subsumed by the new
initialBrowsingContextGroupId attribute, so it is no longer necessary.
Differential Revision: https://phabricator.services.mozilla.com/D85653
This attribute can be used to force non-tab extension browsers to be loaded in
the correct BrowsingContextGroup, and also subsumes the existing
sameProcessAsFrameLoader uses in extension code.
Differential Revision: https://phabricator.services.mozilla.com/D85652
Fix up the browser_tab_label_during_restore.js test to wait for the right number of tab title changes, since the timing of the tab title updating has now changed.
Differential Revision: https://phabricator.services.mozilla.com/D72562
Fix up the browser_tab_label_during_restore.js test to wait for the right number of tab title changes, since the timing of the tab title updating has now changed.
Differential Revision: https://phabricator.services.mozilla.com/D72562
Fix up the browser_tab_label_during_restore.js test to wait for the right number of tab title changes, since the timing of the tab title updating has now changed.
Differential Revision: https://phabricator.services.mozilla.com/D72562
Starting from bug 1533949, the DOMWindowClose event is forwarded to the
`<browser>` element, so there is no need for a custom
"Extension:DOMWindowClose" message any more.
Differential Revision: https://phabricator.services.mozilla.com/D60721
This implements the idea of automatically setting a content proc's
render root based on the render root enclosing the iframe that
points to it. There was a bit of cleanup in here that was a bit
tricky to extract from the core patch revolving around how we
use the Api(...) helper. This was to avoid the situation where
we use the Api(...) helper before our render root is initialized,
when we don't actually have to. I.e., when we just want the root
WebRenderAPI in all cases.
An alternative to this approach could be to fully built out the
WebRender transactions and just queue those up to be sent. However,
transaction building has various side effects which are committed
before the transaction is actually sent, so we would have to build
out some scheme for deferring those as well. This seemed simpler.
Patch primarily written by :dthayer
Differential Revision: https://phabricator.services.mozilla.com/D37078
This implements the idea of automatically setting a content proc's
render root based on the render root enclosing the iframe that
points to it. There was a bit of cleanup in here that was a bit
tricky to extract from the core patch revolving around how we
use the Api(...) helper. This was to avoid the situation where
we use the Api(...) helper before our render root is initialized,
when we don't actually have to. I.e., when we just want the root
WebRenderAPI in all cases.
An alternative to this approach could be to fully built out the
WebRender transactions and just queue those up to be sent. However,
transaction building has various side effects which are committed
before the transaction is actually sent, so we would have to build
out some scheme for deferring those as well. This seemed simpler.
Patch primarily written by :dthayer
Differential Revision: https://phabricator.services.mozilla.com/D37078
This implements the idea of automatically setting a content proc's
render root based on the render root enclosing the iframe that
points to it. There was a bit of cleanup in here that was a bit
tricky to extract from the core patch revolving around how we
use the Api(...) helper. This was to avoid the situation where
we use the Api(...) helper before our render root is initialized,
when we don't actually have to. I.e., when we just want the root
WebRenderAPI in all cases.
An alternative to this approach could be to fully built out the
WebRender transactions and just queue those up to be sent. However,
transaction building has various side effects which are committed
before the transaction is actually sent, so we would have to build
out some scheme for deferring those as well. This seemed simpler.
Patch primarily written by :dthayer
Differential Revision: https://phabricator.services.mozilla.com/D37078
This implements the idea of automatically setting a content proc's
render root based on the render root enclosing the iframe that
points to it. There was a bit of cleanup in here that was a bit
tricky to extract from the core patch revolving around how we
use the Api(...) helper. This was to avoid the situation where
we use the Api(...) helper before our render root is initialized,
when we don't actually have to. I.e., when we just want the root
WebRenderAPI in all cases.
An alternative to this approach could be to fully built out the
WebRender transactions and just queue those up to be sent. However,
transaction building has various side effects which are committed
before the transaction is actually sent, so we would have to build
out some scheme for deferring those as well. This seemed simpler.
Patch primarily written by :dthayer
Differential Revision: https://phabricator.services.mozilla.com/D37078
