This commit removes nsIRemoteTab as a parent class from BrowserParent,
so that BrowserHost is the only concrete implementation of nsIRemoteTab.
Some static_cast's are updated to cast to BrowserHost, and other places
have to be updated to pass a BrowserHost instead of a BrowserParent.
WindowGlobalParent had a getter to return it's managing BrowserParent
as a nsIRemoteTab. I couldn't find a use of this in-tree, so I've just
opt-ed to remove it. If there's a use-case, we can add something back
in.
Differential Revision: https://phabricator.services.mozilla.com/D31444
--HG--
extra : source : 810b7371987139844429d0206f9da6a7701a1efc
This commit removes nsIRemoteTab as a parent class from BrowserParent,
so that BrowserHost is the only concrete implementation of nsIRemoteTab.
Some static_cast's are updated to cast to BrowserHost, and other places
have to be updated to pass a BrowserHost instead of a BrowserParent.
WindowGlobalParent had a getter to return it's managing BrowserParent
as a nsIRemoteTab. I couldn't find a use of this in-tree, so I've just
opt-ed to remove it. If there's a use-case, we can add something back
in.
Differential Revision: https://phabricator.services.mozilla.com/D31444
--HG--
extra : rebase_source : 63070e3c2b90c9134f9106028e124935c8dad009
extra : histedit_source : 807f2ff684d86008077be07b0894f39a925fe778
nsITabParent is exposed to frontend code and is generally used as a representation of a remote tab. We could just rename the interface to nsIBrowserParent and worry about it later, but I think it's better to rename the interface to nsIRemoteTab so that we can later work on splitting the interface away from the PBrowser protocol.
Note: Some frontend code refers to a TabParentId. This commit renames this to RemoteTabId. We need to figure out the purpose of TabId with fission.
Differential Revision: https://phabricator.services.mozilla.com/D28132
--HG--
rename : dom/interfaces/base/nsITabParent.idl => dom/interfaces/base/nsIRemoteTab.idl
extra : rebase_source : 9d8a1790a7bb10195ad063644d1a93d63b2afb72
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
Make the WindowProxyHolder hold a strong reference to a BrowsingContext, as in the future
we might not have a nsPIDOMWindowOuter (if the document is loaded in a different process).
Differential Revision: https://phabricator.services.mozilla.com/D12651
--HG--
extra : moz-landing-system : lando
If class A is derived from class B, then an instance of class A can be
converted to B via a static cast, so a slower QI is not needed.
Differential Revision: https://phabricator.services.mozilla.com/D6861
--HG--
extra : moz-landing-system : lando
This changes the fingerprint resistance code to set mIgnoreXULSize and
mIgnoreXULSizeMode even when there isn't yet a primary content container,
if this is a browser window.
It also removes some dead code and reorders some other logic wrt
mIgnoreXULSizeMode to make it more obvious what that code is doing, and
renames the containing method to distinguish it more clearly from some
other Load...Attributes methods.
MozReview-Commit-ID: LJqRWeta6XV
--HG--
extra : rebase_source : 9d83c83aa2ee8d3314e3f94f157b956608e927d8
Add an anonymous XUL tooltip node to toplevel non-XUL windows. Setup a
nsXULTooltipListener on non-XUL nsXULWindows. Make nsXULTooltipListener
always use the default tooltip in the non-XUL case.
MozReview-Commit-ID: Koe5m8PwMQM
--HG--
extra : rebase_source : 242180e957758b51c589452e35deadac5ab06d9e
Previously, with early first paint enabled, nsXULWindow incorrectly loaded the
persisted window settings from about:blank and would only load them once.
Instead, load the settings before starting layout.
MozReview-Commit-ID: 6K4ofkbmHHb
--HG--
extra : rebase_source : 7bcd804cfabbd47ee5a747800a2ef81852213889
This should allow us to figure out what's killing the window mid-flight, in case
there's something to fix in the chrome JS code.
MozReview-Commit-ID: 1xx1AVdspB2
Using concrete class types with static IIDs in QueryInterface methods is a
pretty common pattern which isn't supported by any existing helper macros.
That's lead to separate ad-hoc implementations, with varying degrees of
dodginess, being scattered around the tree.
This patch adds a helper macro with a canonical (and safe) implementation, and
updates existing ad-hoc users to use it.
MozReview-Commit-ID: HaTGF7MN5Cv
--HG--
extra : rebase_source : ace930129d85960d22bc3048ca3bb19bbbd4a63e
extra : histedit_source : 03a87f746d957789d41381e4e1bfcc4fd7eebaf2%2C9c5bae9feeeef7721105db67be0f83e0ded66bb7
Move tracking of persistent window state into nsXULWindow. Also, move
special handling of the width/height of the window into nsXULWindow.
MozReview-Commit-ID: LOmHGyYeNSU
--HG--
extra : rebase_source : bcea16eb6209ff789948644a64968a7325cea4ef
When SetSize etc. are called before OnChromeLoaded has been invoked,
the functions assume that the window initialization code wants to size
the window specifically, and thus ignore the values from the <window>
element.
However, bug 1439875 changes the behavior so that SizeShell is also
invoked before OnChromeLoaded, which confuses the functions above, and
causes some of the attributes not to be loaded properly.
This patch adds a separate flag to avoid ignoring those attributes when
those functions are invoked as part of SizeShell itself.
It can cause extra reflow if the window is opened in maximized state,
and thus the new whitelist items. They may be fixed by bug 1448199.
MozReview-Commit-ID: 7jT8w9KGmzy
--HG--
extra : rebase_source : d970be5b1ae0588f6b0b63e2bd6a711853c82478
I want this behind a pref so that I can investigate other bugs without building
locally.
MozReview-Commit-ID: FWbGUxNbbm
--HG--
extra : rebase_source : 546ace867858f17b543bd11ef908c10fa63a022f
When SetSize etc. are called before OnChromeLoaded has been invoked,
the functions assume that the window initialization code wants to size
the window specifically, and thus ignore the values from the <window>
element.
However, bug 1439875 changes the behavior so that SizeShell is also
invoked before OnChromeLoaded, which confuses the functions above, and
causes some of the attributes not to be loaded properly.
This patch adds a separate flag to avoid ignoring those attributes when
those functions are invoked as part of SizeShell itself.
MozReview-Commit-ID: 7jT8w9KGmzy
--HG--
extra : rebase_source : 7bcc0b1fe96207561fbfd255c976cce695c1da8f
Ryan Hunt
Gurzau Raul
Myk Melez
Coroiu Cristina
Razvan Maries
Sylvestre Ledru
meandave
Felipe Gomes
Cosmin Sabou
Florian Quèze
Emilio Cobos Álvarez
Peter Van der Beken
Andrew McCreight
Gijs Kruitbosch
Brian Grinstead
Brendan Dahl
Mike Conley
Kris Maglione
Adrian Wielgosik
Boris Zbarsky
Xidorn Quan
Henri Sivonen
Narcis Beleuzu
Andreea Pavel