This is done differently depending on whether the Private Browsing window is the initial one, or if it's a new window from a running application. In the former case, we're still not setting it up early enough -- the window will initially show up in one icon, and then switch to the other one after we've adjusted the AUMID.
Regardless, the fact that we're doing it for every new window appears to mean that other places that require it (such as GeckoChildProcessHost.cpp) will Do The Right Thing (because they'll pull the cached version that `GetAppUserModelID` finds).
This behind a pref for now both because of the issue noted above, as well as the fact that we're waiting on finalized branding for this.
Differential Revision: https://phabricator.services.mozilla.com/D138194
This is done differently depending on whether the Private Browsing window is the initial one, or if it's a new window from a running application. In the former case, we're still not setting it up early enough -- the window will initially show up in one icon, and then switch to the other one after we've adjusted the AUMID.
Regardless, the fact that we're doing it for every new window appears to mean that other places that require it (such as GeckoChildProcessHost.cpp) will Do The Right Thing (because they'll pull the cached version that `GetAppUserModelID` finds).
This behind a pref for now both because of the issue noted above, as well as the fact that we're waiting on finalized branding for this.
Differential Revision: https://phabricator.services.mozilla.com/D138194
This is done differently depending on whether the Private Browsing window is the initial one, or if it's a new window from a running application. In the former case, we're still not setting it up early enough -- the window will initially show up in one icon, and then switch to the other one after we've adjusted the AUMID.
Regardless, the fact that we're doing it for every new window appears to mean that other places that require it (such as GeckoChildProcessHost.cpp) will Do The Right Thing (because they'll pull the cached version that `GetAppUserModelID` finds).
This behind a pref for now both because of the issue noted above, as well as the fact that we're waiting on finalized branding for this.
Differential Revision: https://phabricator.services.mozilla.com/D138194
This is done differently depending on whether the Private Browsing window is the initial one, or if it's a new window from a running application. In the former case, we're still not setting it up early enough -- the window will initially show up in one icon, and then switch to the other one after we've adjusted the AUMID.
Regardless, the fact that we're doing it for every new window appears to mean that other places that require it (such as GeckoChildProcessHost.cpp) will Do The Right Thing (because they'll pull the cached version that `GetAppUserModelID` finds).
This behind a pref for now both because of the issue noted above, as well as the fact that we're waiting on finalized branding for this.
Differential Revision: https://phabricator.services.mozilla.com/D138194
This makes sure to clear and set the value more consistently when replacing
documents within a WindowGlobal, and makes sure to include the relevant flag in
the initializer.
In addition, the place where the flag is set is moved ahead to happen before
the call to `Embed` so that the information is ready before the window is
created.
Differential Revision: https://phabricator.services.mozilla.com/D119815
And have it mirror in the parent process more automatically.
The docShellIsActive setter in the browser-custom-element side needs to
be there rather than in the usual DidSet() calls because the
AsyncTabSwitcher code relies on getting an exact amount of notifications
as response to that specific setter. Not pretty, but...
BrowserChild no longer sets IsActive() on the docshell itself for OOP
iframes. This fixes bug 1679521. PresShell activeness is used to
throttle rAF as well, which handles OOP iframes nicely as well.
Differential Revision: https://phabricator.services.mozilla.com/D96072
When window is PiP window on Windows7, WS_EX_COMPOSITED is set to suppress flickering during resizing with hardware acceleration as a workaround.
PiP window detection in nsAppShellService::JustCreateTopWindow() mimics Linux/Gtk implementation.
Differential Revision: https://phabricator.services.mozilla.com/D77663
The enforcement is only important when users are able to resize the windows. Otherwise,
we let Gecko set the window dimensions to whatever dimensions they'd like.
Differential Revision: https://phabricator.services.mozilla.com/D78538
This value is determined in Parent process and passed down to nsDocShell. Delete
the messages to pass the setting down and set it on the BrowsingContext in the
Parent process.
Refactor the code that determines to opt-out of using global history. Code
inspection determines that windowless browsing contexts want to opt-out as well
as any frame with `disableglobalhistory` attribute set on it.
Differential Revision: https://phabricator.services.mozilla.com/D72279
There were previously a number of different APIs for creating BrowsingContext
instances. This simplifies them into two major cases: "CreateDetached", which
allows for creating BrowsingContexts which are related to other
BrowsingContexts, and "CreateIndependent" which creates new, fully unrelated,
browsing contexts.
Differential Revision: https://phabricator.services.mozilla.com/D71237
There were previously a number of different APIs for creating BrowsingContext
instances. This simplifies them into two major cases: "CreateDetached", which
allows for creating BrowsingContexts which are related to other
BrowsingContexts, and "CreateIndependent" which creates new, fully unrelated,
browsing contexts.
Differential Revision: https://phabricator.services.mozilla.com/D71237
There were previously a number of different APIs for creating BrowsingContext
instances. This simplifies them into two major cases: "CreateDetached", which
allows for creating BrowsingContexts which are related to other
BrowsingContexts, and "CreateIndependent" which creates new, fully unrelated,
browsing contexts.
Differential Revision: https://phabricator.services.mozilla.com/D71237
There were previously a number of different APIs for creating BrowsingContext
instances. This simplifies them into two major cases: "CreateDetached", which
allows for creating BrowsingContexts which are related to other
BrowsingContexts, and "CreateIndependent" which creates new, fully unrelated,
browsing contexts.
Differential Revision: https://phabricator.services.mozilla.com/D71237
There were previously a number of different APIs for creating BrowsingContext
instances. This simplifies them into two major cases: "CreateDetached", which
allows for creating BrowsingContexts which are related to other
BrowsingContexts, and "CreateIndependent" which creates new, fully unrelated,
browsing contexts.
Differential Revision: https://phabricator.services.mozilla.com/D71237
This patch builds on top of part 7.1 by creating this object within
nsWindowWatcher and ContentParent to carry the relevant information through
provider interfaces when creating new content windows. The nsOpenWindowInfo
object is not created for new chrome windows.
This patch does not propagate these flags all of the way through to the
nsFrameLoader. That change is performed in later parts to keep each part
smaller.
Differential Revision: https://phabricator.services.mozilla.com/D67051
--HG--
extra : moz-landing-system : lando
Previously, a load of the URI within a chrome docshell would start before the
chrome docshell has had a chance to be configured. This could cause problems, as
the load would be configured incorrectly.
After these changes, starting the load is delayed until after nsILoadContext
configuration is complete.
Differential Revision: https://phabricator.services.mozilla.com/D67048
--HG--
extra : moz-landing-system : lando
This could cause issues, as we could incorrectly override the decision made by
nsWindowWatcher, and then override the decision again after the method returns.
This could cause the initial content browser to be configured incorrectly.
Differential Revision: https://phabricator.services.mozilla.com/D67043
--HG--
extra : moz-landing-system : lando
This patch builds on top of part 7.1 by creating this object within
nsWindowWatcher and ContentParent to carry the relevant information through
provider interfaces when creating new content windows. The nsOpenWindowInfo
object is not created for new chrome windows.
This patch does not propagate these flags all of the way through to the
nsFrameLoader. That change is performed in later parts to keep each part
smaller.
Differential Revision: https://phabricator.services.mozilla.com/D67051
--HG--
extra : moz-landing-system : lando
Previously, a load of the URI within a chrome docshell would start before the
chrome docshell has had a chance to be configured. This could cause problems, as
the load would be configured incorrectly.
After these changes, starting the load is delayed until after nsILoadContext
configuration is complete.
Differential Revision: https://phabricator.services.mozilla.com/D67048
--HG--
extra : moz-landing-system : lando
This could cause issues, as we could incorrectly override the decision made by
nsWindowWatcher, and then override the decision again after the method returns.
This could cause the initial content browser to be configured incorrectly.
Differential Revision: https://phabricator.services.mozilla.com/D67043
--HG--
extra : moz-landing-system : lando
There are all sorts of lifecycle issues which arise from making DocShell
responsible for discarding BrowsingContexts. In this particular bug, we tend
to run into them in cases where we create a BrowsingContext for a FrameLoader,
and then never create a DocShell for it, leading to it never being destroyed.
But there are myriad other issues as well.
This patch moves the responsibility for BrowsingContext lifecycle management
to the FrameLoader/FrameLoaderOwner, rather than the DocShell, which makes
things more consistent, and more closely aligns with spec-defined behavior.
Differential Revision: https://phabricator.services.mozilla.com/D59008
--HG--
extra : moz-landing-system : lando
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55444
--HG--
extra : moz-landing-system : lando
* Removed the STATUS_LINK constant.
* Removed the statusType parameter from nsIWebBrowserChrome::setStatus.
* Removed the setStatusWithContext method. No one uses the information from
statusContext.
* Removed the nsIWebBrowserChrome2 interface as setStatusWithContext was the
only method.
Differential Revision: https://phabricator.services.mozilla.com/D55195
--HG--
extra : moz-landing-system : lando
Ben Hearsum
Butkovits Atila
Marian-Vasile Laza
Csoregi Natalia
Mark Smith
Botond Ballo
Nika Layzell
Edgar Chen
Emilio Cobos Álvarez
Kris Maglione
Kashav Madan
Eden Chuang
sotaro
Mike Conley
Dan Glastonbury
Razvan Maries
Bogdan Tara
Narcis Beleuzu
Andreea Pavel
Dorel Luca
Tetsuharu Ohzeki
Cosmin Sabou
Gabriele Svelto
Masatoshi Kimura
Matt Woodrow