Original patch by Brendan Dahl <bdahl@mozilla.com>.
The change to nsCocoaWindow appears to be necessary because the nsMenuBarX
only seems to get created _after_ nsCocoaWindow::paintMenubarForWindow runs
for the created window, which is too late to Paint the native menu bar, but
also happens before nsCocoaWindow::sendToplevelActivateEvents runs, which
is too early for the nsCocoaWindow::SetMenuBar code's check for
toplevelActiveState on the WindowDelegate to return true.
So instead of checking for the toplevelActiveState, we now check if the
window for the newly created nsMenuBarX is the main window, and if so,
then we Paint it.
Differential Revision: https://phabricator.services.mozilla.com/D46202
See bug for justification. This patch aims to display a blank window prior to
loading/prefetching xul.dll. It also has a placeholder for drawing a
skeleton UI into that window. Note that this is disabled by default based on
a registry value, as there are still kinks to work out (for instance, what
happens if we aren't actually going to display a window, because, say, Firefox
is already running.) This just gives a basic implementation to dogfood, and
facilitates distributing work across multiple contributors.
Onto the details. The patch achieves its goal by creating a window and
assigning its handle to a static variable, which will be consumed inside
nsWindow::Create by the first toplevel window we want to make. nsWindow::Create
will take ownership of the window handle, restyle it to its own liking, and
then proceed as if everything is normal and it had created the window itself.
Differential Revision: https://phabricator.services.mozilla.com/D86263
See bug for justification. This patch aims to display a blank window prior to
loading/prefetching xul.dll. It also has a placeholder for drawing a
skeleton UI into that window. Note that this is disabled by default based on
a registry value, as there are still kinks to work out (for instance, what
happens if we aren't actually going to display a window, because, say, Firefox
is already running.) This just gives a basic implementation to dogfood, and
facilitates distributing work across multiple contributors.
Onto the details. The patch achieves its goal by creating a window and
assigning its handle to a static variable, which will be consumed inside
nsWindow::Create by the first toplevel window we want to make. nsWindow::Create
will take ownership of the window handle, restyle it to its own liking, and
then proceed as if everything is normal and it had created the window itself.
Differential Revision: https://phabricator.services.mozilla.com/D86263
See bug for justification. This patch aims to display a blank window prior to
loading/prefetching xul.dll. It also has a placeholder for drawing a
skeleton UI into that window. Note that this is disabled by default based on
a registry value, as there are still kinks to work out (for instance, what
happens if we aren't actually going to display a window, because, say, Firefox
is already running.) This just gives a basic implementation to dogfood, and
facilitates distributing work across multiple contributors.
Onto the details. The patch achieves its goal by creating a window and
assigning its handle to a static variable, which will be consumed inside
nsWindow::Create by the first toplevel window we want to make. nsWindow::Create
will take ownership of the window handle, restyle it to its own liking, and
then proceed as if everything is normal and it had created the window itself.
Differential Revision: https://phabricator.services.mozilla.com/D86263
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 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
There's only one test that can potentially rely on this, and still passes
with this patch:
toolkit/components/windowwatcher/test/browser_new_content_window_chromeflags.js
More to the point, this doesn't work with e10s whatsoever already, and seems
content cannot change the scrollbar visibility anymore, and chrome code doesn't
do it either.
Depends on D57182
Differential Revision: https://phabricator.services.mozilla.com/D57184
--HG--
extra : moz-landing-system : lando
Initially this was going to be a simple cleanup: Remove some useless namespaces
here and there and so on, remove `using` statements from the header and so on.
But unfortunately, DOMIntersectionObserver.h (which is included in Element.h,
unnecessarily) ended up exposing `Element` unnamespaced to a lot of code, so I
had to fix that.
Differential Revision: https://phabricator.services.mozilla.com/D55316
--HG--
extra : moz-landing-system : lando
nsXULWindow is no longer XUL specific and is somewhat confusing name.
Differential Revision: https://phabricator.services.mozilla.com/D51486
--HG--
rename : xpfe/appshell/nsXULWindow.cpp => xpfe/appshell/AppWindow.cpp
rename : xpfe/appshell/nsXULWindow.h => xpfe/appshell/AppWindow.h
rename : xpfe/appshell/nsIXULWindow.idl => xpfe/appshell/nsIAppWindow.idl
extra : moz-landing-system : lando
nsXULWindow is no longer XUL specific and is somewhat confusing name.
Differential Revision: https://phabricator.services.mozilla.com/D51486
--HG--
rename : xpfe/appshell/nsXULWindow.cpp => xpfe/appshell/AppWindow.cpp
rename : xpfe/appshell/nsXULWindow.h => xpfe/appshell/AppWindow.h
rename : xpfe/appshell/nsIXULWindow.idl => xpfe/appshell/nsIAppWindow.idl
extra : moz-landing-system : lando
nsXULWindow is no longer XUL specific and is somewhat confusing name.
Differential Revision: https://phabricator.services.mozilla.com/D51486
--HG--
rename : xpfe/appshell/nsXULWindow.cpp => xpfe/appshell/AppWindow.cpp
rename : xpfe/appshell/nsXULWindow.h => xpfe/appshell/AppWindow.h
rename : xpfe/appshell/nsIXULWindow.idl => xpfe/appshell/nsIAppWindow.idl
extra : moz-landing-system : lando
harry
Mike Conley
Doug Thayer
Dorel Luca
Razvan Maries
Edgar Chen
Xidorn Quan
Nika Layzell
Mihai Alexandru Michis
Cosmin Sabou
Emilio Cobos Álvarez
Brendan Dahl