Set IsDocumentPiP immediately after creating the chrome window, instead of
after the browser chrome loads. This ensures browser CSS immediately gets the
picture-in-picture display-mode.
Differential Revision: https://phabricator.services.mozilla.com/D276863
This reverts commit 2fe2da3e4b.
Revert "Bug 2004407 - Get policy container for initial about:blank from entry global. r=smaug"
This reverts commit dbad5d1e6b.
Make sure that navigations from Location and Window.open perform correct
conversion of history handling when passed "auto".
Differential Revision: https://phabricator.services.mozilla.com/D266519
Make sure that navigations from Location and Window.open perform correct
conversion of history handling when passed "auto".
Differential Revision: https://phabricator.services.mozilla.com/D266519
Make sure that navigations from Location and Window.open perform correct
conversion of history handling when passed "auto".
Differential Revision: https://phabricator.services.mozilla.com/D266519
Make sure that navigations from Location and Window.open perform correct
conversion of history handling when passed "auto".
Differential Revision: https://phabricator.services.mozilla.com/D266519
AppWindow::GetMainWidget() is just mWindow. Add a helper to simplify
GetMainWidget() usage and use it across the tree, simplifying users.
Differential Revision: https://phabricator.services.mozilla.com/D258744
We are making changes to many files. Very huge chunk of the changes are just renaming CSP -> PolicyContainer. Part 1 and part 2 are solely separated as frontend and backend. The unfortunate thing is, I mistakenly placed IDL changes in part 1, and many of those IDL changes affect frontend code too. I'm sorry for this inconvinience and hard to review patch(es).
(FWIW before this rewrite we had another patch stack. It is 25 patches and I believe isn't as comprehensive as this one. It also didn't replace CSP's inheritance but was copied alongside with CSP, but we decided to change our method and make policy conttainer contain CSP and copy it around after some discussion and reviews)
Differential Revision: https://phabricator.services.mozilla.com/D249248
This reverts commit efd9a5ba48.
Revert "Bug 1968644 - Part 9: Add more tests for loads triggered by tracking scripts. r=valentin,anti-tracking-reviewers,emz"
This reverts commit 7d5c3e1c1c.
Revert "Bug 1968644 - Part 8: Populate the triggeringFirstPartyClassificationFlags and triggeringThirdPartyClassificationFlags for WebSocket requests. r=valentin,necko-reviewers"
This reverts commit 53a783a51e.
Revert "Bug 1968644 - Part 7: Add tests. r=necko-reviewers,anti-tracking-reviewers,emz,valentin"
This reverts commit e52f034955.
Revert "Bug 1968644 - Part 6: Populate triggeringFirstPartyClassificationFlags and triggeringThirdPartyClassificationFlags during channel creation. r=necko-reviewers,kershaw"
This reverts commit f564c21b37.
Revert "Bug 1968644 - Part 5: Populate triggeringFirstPartyClassificationFlags and triggeringThirdPartyClassificationFlags for CSS loads. r=emilio"
This reverts commit 8a8fd7bacc.
Revert "Bug 1968644 - Part 4: Populate triggeringFirstPartyClassificationFlags and triggeringThirdPartyClassificationFlags for loads. r=smaug,necko-reviewers"
This reverts commit 7b3ba3b668.
Revert "Bug 1968644 - Part 3: Populate the triggeringFirstPartyClassificationFlags and triggeringThirdPartyClassificationFlags for fetch requests. r=valentin,smaug"
This reverts commit 08f090244f.
Revert "Bug 1968644 - Part 2: Intorduce the ClassificationFlags to nsIClassifiedChannel.idl. r=dimi,necko-reviewers,valentin"
This reverts commit b8c01cd77c.
Revert "Bug 1968644 - Part 1: Introduce triggeringFirstPartyClassificationFlags and triggeringThirdPartyClassificationFlags to LoadInfo. r=necko-reviewers,kershaw"
This reverts commit a7619a72b4.
By bug 1910849, you suggest that we use `MOZ_RELEASE_ASSERT`, but it
still may be called on error case. So I would like to change to
MOZ_ASSERT instead.
Differential Revision: https://phabricator.services.mozilla.com/D234924
Chrome window has one browser element only in GeckoView. So even if
browser (Fenix etc) shows tabs, it is window.
When creating chrome window, we have to call Java code via
`nsIBrowserDOMWindow.createContentWindow` or
`nsIBrowserDOMWindow.createContentWindowInFrame`. So if we open
`geckoview.xhtml` directly, `geckoview.xhtml` throws an exception due to
missing initializing parameters.
Although `test_notification_serviceworker_openWindow.html` modifies
`browser.link.open_newwindow` preference, some values won't work since
`OpenWindowWithRemoteTab` is used to create browser and window in
`ContentParent::CommonCreateWindow`.
`OpenWindowWithRemoteTab` opens geckoview.xhtml directly, so it doesn't
work on GeckoView.
I would like to avoid this call and OpenWindowWithRemoteTab should
return an error in GeckoView immediately.
Differential Revision: https://phabricator.services.mozilla.com/D231055
Chrome window has one browser element only in GeckoView. So even if
browser (Fenix etc) shows tabs, it is window.
When creating chrome window, we have to call Java code via
`nsIBrowserDOMWindow.createContentWindow` or
`nsIBrowserDOMWindow.createContentWindowInFrame`. So if we open
`geckoview.xhtml` directly, `geckoview.xhtml` throws an exception due to
missing initializing parameters.
Although `test_notification_serviceworker_openWindow.html` modifies
`browser.link.open_newwindow` preference, some values won't work since
`OpenWindowWithRemoteTab` is used to create browser and window in
`ContentParent::CommonCreateWindow`.
`OpenWindowWithRemoteTab` opens geckoview.xhtml directly, so it doesn't
work on GeckoView.
I would like to avoid this call and OpenWindowWithRemoteTab should
return an error in GeckoView immediately.
Differential Revision: https://phabricator.services.mozilla.com/D231055
Do it at the same time as UpdateRemoteFrameEffects() (so, intersection
observer timing). Otherwise we can see flickering sometimes from the
resize with the previous patch (and this should be less work, when we
resize).
Non-remote frames need to synchronously communicate their resizes
(because JS could access the frame), but that's not an issue for
remote frames.
This should also more reliably prevent issues like bug 1910887 or like
bug 1764655, and paves the way for fixing bug 1750189 (which stalled) in
a similar fashion.
I tested this in a build with a couple hundred tabs open and it doesn't
measurably show up. I think we should consider not communicating resizes
to background tabs / hidden remote iframes, at least for top levels.
Differential Revision: https://phabricator.services.mozilla.com/D221405
Do it at the same time as UpdateRemoteFrameEffects() (so, intersection
observer timing). Otherwise we can see flickering sometimes from the
resize with the previous patch (and this should be less work, when we
resize).
Non-remote frames need to synchronously communicate their resizes
(because JS could access the frame), but that's not an issue for
remote frames.
This should also more reliably prevent issues like bug 1910887 or like
bug 1764655, and paves the way for fixing bug 1750189 (which stalled) in
a similar fashion.
I tested this in a build with a couple hundred tabs open and it doesn't
measurably show up. I think we should consider not communicating resizes
to background tabs / hidden remote iframes, at least for top levels.
Differential Revision: https://phabricator.services.mozilla.com/D221405
Michael Kaply