Last Comment Bug 71895 - Remove Hidden Window from Linux and Windows builds
: Remove Hidden Window from Linux and Windows builds
Status: NEW
pseudo-completed
: addon-compat, perf
Product: Core
Classification: Components
Component: XUL (show other bugs)
: Trunk
: All All
: -- normal with 9 votes (vote)
: Future
Assigned To: Nobody; OK to take it and work on it
: John Morrison
Mentors:
Depends on: 67368 503879 700277 700643
Blocks: fatfennec 959776 44809 70534
  Show dependency treegraph
 
Reported: 2001-03-13 17:26 PST by Dan M
Modified: 2015-10-01 07:49 PDT (History)
44 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
replaces most of the important uses of hidden window (73.81 KB, patch)
2001-04-10 17:41 PDT, Dan M
no flags Details | Diff | Review
Patch to create hidden window on demand (14.88 KB, patch)
2011-10-19 11:37 PDT, Neil Deakin
no flags Details | Diff | Review

Description Dan M 2001-03-13 17:26:24 PST
I believe Hidden Window is used only to act as a parent for otherwise parentless 
dialogs, and it's a bad parent. It should be possible now to remove it from the 
process of opening parentless windows entirely (now that task/bug 67368 is done).

This is important for embedding, since it looks like we'll never be able to 
guarantee proper parents for all dialogs. And since without this change, that 
implies a dependency on Hidden Window, which is missing from embedded builds.

(Hidden Window can't be removed from the Macintosh build, since there it serves a 
second purpose of holding the menubar when no visible window is present.)
Comment 1 Dan M 2001-03-30 12:46:43 PST
(Note: implementation for this bug involves using WindowWatcher to open windows 
without parents, but for a dependent window with no parent specified, to attempt 
to attach it to the topmost window, whatever it is.)
Comment 2 Dan M 2001-04-10 17:41:03 PDT
Created attachment 30353 [details] [diff] [review]
replaces most of the important uses of hidden window
Comment 3 Javier Delgadillo 2001-04-10 17:44:52 PDT
r=javi for the psm-glue patches.

Eventually I'd like to see a #define for the window watcher contract ID just in
case it were to change one day.  :)
Comment 4 Dan M 2001-04-10 18:30:29 PDT
Patch is in. Hidden window is now used in only these places:

where it's defined and created
extensions/transformiix/source/xml/parser/nsSyncLoader.cpp
there's a suspicious-sounding extern function used in modules/oji/src/scd.cpp
by XPConnect. it's where SafeJSContexts come from. D'oh!

Hidden Window is evil. It'd be nice to get rid of it, and we especially need to 
excise it from embedding distributions. jband, peterv, any thoughts?

(About contract IDs: I've been trying to figure out how best to use them. I know 
that defining them in the .idl file, a thing we do often, is just wrong. I'm 
putting window watcher's contract ID in nsWindowWatcher.h (not nsI...), but I 
still feel dirty doing that. And of course it's useless in JavaScript. I'll get 
enlightenment on that sometime soon.)
Comment 5 Chris Siebenmann 2001-04-11 14:02:26 PDT
 As a heads up warning, it appears that this may have broken remote control
of Mozilla on Unix (or at least Linux).
Comment 6 John Bandhauer 2001-04-11 14:17:46 PDT
[cc'ing DOM and security folk]

Yeah. This may break other stuff too. XPConnect itself does not care about this. 
But any call from native code into JS via xpconnect has to run on *some* 
JSContext. It happens that some DOM oriented code *cares* whether or not this is 
a JSContext created by the DOM system for a window or not. This especially 
matters to the caps security manager. Thus, we have code to tell the thread 
JSContext stack service thingy in the xpconnect module to use the hidden window 
as the 'safe' JSContext to use on the main thread. This smoothes over the 
transition from native to JS calls in lots of cases. Remove that at your own 
peril.
Comment 7 Dan M 2001-04-11 15:25:20 PDT
Pity me for not realizing this earlier. This is a real problem for embedded 
distributions, there not being a hidden window in embedding apps. Is there no 
solution other than forcing embedding apps to create a hidden window for us? Oh, 
moan.
Comment 8 Chris Siebenmann 2001-04-12 13:49:30 PDT
 Until a full solution is figured out, can I agitate for this bug'fix' to
be reverted, since it causes at least Mozilla remote control to break? (It's
my impression from reading this bug that not having it in is not breaking
anything vital, which may be incorrect.)
Comment 9 Dan M 2001-04-12 19:13:30 PDT
-remote "openurl(<url>,new-window)" has been fixed. Sorry about that. We now 
return you to your original programming.

  Use of hidden window has been largely removed, though there will probably be 
ramifications. The only one I can foresee is what John pointed out above. Mozilla 
will be unaffected. But embedded installations, lacking a hidden window, when 
under conditions where a JS context is needed, will get one that wasn't generated 
inside a window, and therefore will be missing some bits that code like caps 
probably depends on.
  The exact ramifications of this are currently unknown. Top Men profess 
ignorance. A complete fix will involve a lot of digging into clients of 
JSContexts which can be called directly from C code without JS on the execution 
stack, discovering what improperly initialised features of the generted context 
are important, and faking something. This will be a lot of work.
  I'm going to say that this task is finished enough for an embedded pre-release 
and push off the remaining work one milestone.
Comment 10 Alex Bischoff 2001-04-18 12:47:50 PDT
I've run into some problems with windows integration, and timeless@mac.com
suggested that I mention it here. 

Originally from bug 59078:
"I hope that I'm not being redundant, but I thought I'd give share my situation.
I regularly use the daily builds on Win2k and, for several days now, clicking on
urls in my email client does nothing (clicking on urls from icq doesn't work
either). Normally, I'd expect Mozilla to load the url -- hopefully in an
existing browser window, but even loading it in a new browser window would be
better than nothing ;). I would have filed a bug report for this, but I wasn't
sure if this behavior was covered by this bug report."

If indeed this bug is the cause of my woes, then I propose the nsdogfood keyword.
Comment 11 Dan M 2001-04-25 12:10:00 PDT
That's bug 50424, fixed by law on 19 Apr.
Comment 12 Marek Z. Jeziorek 2002-03-13 12:51:43 PST
removing topembed per edt triage.
danm, where do you stand in completing this?
what kind of speedup would we get if this was done?
Comment 13 Dan M 2002-03-13 15:19:04 PST
Oh, on linux and windows startup time would improve about 2%. The main reason to
do this would be to correct what seems like a mistake before it's immortalized
in finalised interfaces. But the mistake is so widely capitalised on... At one
time I knew how to fix every use but one. But that one was very hard to fix and
more have crept in since. I opine that this bug should lose mindshare to other
more visible flaws.
Comment 14 Andrew Hagen 2002-03-13 18:15:41 PST
I disagree, but only with respect. A 2% startup increase would be nice. Removing
the hidden window before 1.0 is the right thing to do at the right time. The
breakage will not affect many users, and can be fixed.
Comment 15 Andrew Hagen 2002-04-20 11:24:05 PDT
After this comment, I'll shut up. If we are going to back out the links toolbar
because it is causing a 3% performance reduction in startup time (see bug
138496), then we should also get rid of the hidden window for causing a 2%
reduction. Now I'm shutting up.
Comment 16 dan 2002-05-14 06:46:12 PDT
I don't know if this is related to the 'hidden window' being discussed here, but:

I'm using Forte for Java on Debian GNU/Linux, and have successfully persuaded
the debugger to launch Mozilla in the past (Moz 0.9.2). Forte uses "xwininfo
-name Netscape" to find a running instance of Netscape, so I just changed it to
use "xwininfo -name Mozilla", and that worked with 0.9.2. This seems a prevalent
method for browser integration, for example konqueror provides a hidden window
called "konqueror".

Now I am running 0.9.8 and it can no longer find the running Mozilla instance.
Is this because the window has been removed. "xwininfo -name Mozilla" now says
no window with that name exists.

Or is there now another window name Forte should be looking for? Or the window 
been put pack in to builds >0.9.8?
Comment 17 bbz 2003-10-25 11:24:28 PDT
In Mac OS X 10.3 (Panther) there is a new feature called Exposé that shrinks all
windows and shows them all tiled so the user can switch windows quickly. 
Unfortunately the hidden window shows up and looks really unprofessional.  If it
can't be removed from mac builds, it at least shouldn't show up in Exposé.
Comment 18 bbz 2003-10-25 11:29:22 PDT
The OS X Exposé problem is bug 223545.
Comment 19 Neil Deakin 2011-10-19 11:37:00 PDT
Created attachment 568135 [details] [diff] [review]
Patch to create hidden window on demand

This patch takes another step of only creating the hidden window when something uses it. A default Windows and Linux build will not create it.

This could break any extensions that rely on setting properties on the hidden window. A next step is to remove the hidden window entirely.

There is still some code that depends on the hidden window:
 - WidgetTraceEvent.cpp, Windows only code used or will be used for some performance tests (not startup though)
 - some mozmill tests
 - Mac still uses it for the no-windows-open case. Ideally, a patch could be created that would only create the hidden window after a window is closed.
Comment 20 Masatoshi Kimura [:emk] 2011-10-19 17:25:27 PDT
Is WM_POWERBROADCAST message handled correctly without the hidden window?
https://mxr.mozilla.org/mozilla-central/source/widget/src/windows/nsWindow.cpp#4860
Comment 21 Neil Deakin 2011-10-20 05:40:22 PDT
(In reply to Masatoshi Kimura [:emk] from comment #20)
> Is WM_POWERBROADCAST message handled correctly without the hidden window?
> https://mxr.mozilla.org/mozilla-central/source/widget/src/windows/nsWindow.
> cpp#4860

It is not handled. The comments there suggest this code is to prevent duplicate messages, but the code in the case block for 'wake' appears to is written such that the wake notification will be sent multiple times anyway (for all three message types), as the documentation for the WM_POWERBROADCAST message suggests that several of the PBT_APMRESUME* messages can be sent in sequence.

You could handle this by caching the sleep/wake state in a static variable, or switching to using an event for notification instead of an observer.
Comment 22 Eddy Bruel [:ejpbruel] 2012-01-05 08:03:04 PST
Actually, the addon-sdk has multiple use cases for which we depend on the hidden window at the moment. In particular, we use the hidden window as a way to load a 'background DOM' (a DOM that is independent of the lifetime of any particular window). For a full overview of these use cases, see: https://etherpad.mozilla.org/background-window

Now, the hidden window hasn't been a particularly good solution to our problem (in particular, at least one add-on that was approved by AMO completely replaced the document loaded in the hidden window, thus unloading any documents that we had loaded on it previously), so I'm all for getting rid of it. However, we can't do so without at least providing an alternative for what we want to do, or we could be faced with major breakage throughout the add-on SDK.

For most of our use cases, we don't really need DOM access, and all we really need is a 'background sandbox' (a sandbox  that is independent of the lifetime of any particular window). This should be relatively simple to implement. However, for at least some use cases, we still need a 'background DOM'. I imagine this would be implemented as a <browser> element that isn't associated with any particular window. I have no idea how hard something like that would be, but I think it's safe to say that it would take a significant amount of time.

(In reply to Dan M from comment #0)
> I believe Hidden Window is used only to act as a parent for otherwise
> parentless 
> dialogs, and it's a bad parent. It should be possible now to remove it from
> the 
> process of opening parentless windows entirely (now that task/bug 67368 is
> done).
> 
> This is important for embedding, since it looks like we'll never be able to 
> guarantee proper parents for all dialogs. And since without this change,
> that 
> implies a dependency on Hidden Window, which is missing from embedded builds.
> 
> (Hidden Window can't be removed from the Macintosh build, since there it
> serves a 
> second purpose of holding the menubar when no visible window is present.)
Comment 23 Neil Deakin 2012-01-05 09:01:11 PST
(In reply to Eddy Bruel [:ejpbruel] from comment #22)
> Actually, the addon-sdk has multiple use cases for which we depend on the
> hidden window at the moment. In particular, we use the hidden window as a
> way to load a 'background DOM' (a DOM that is independent of the lifetime of
> any particular window). For a full overview of these use cases, see:
> https://etherpad.mozilla.org/background-window

Well, you can already parse, create and access documents in the background without a window.

What you actually want is:
 - access to apis that are dependent on the javascript 'window' object.
 - access to a means of getting some rendering of a document with no associated window.
Comment 24 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-08-07 12:39:07 PDT
We've since added several uses of the hidden window:
- PageThumbs.jsm uses it to create canvas elements
- mozmill and peptest use it for something
- FrameWorker.jsm uses it to access window.* APIs for its sandbox
- toolkit/identity/Sandbox.jsm uses it to provide generic "hidden iframe" functionality

We'd need to find alternative solutions for these users before any progress can be made here.
Comment 25 Richard Newman [:rnewman] 2014-03-17 20:16:05 PDT
mfinkle notes that the hidden window adds half a meg to Fennec's heap, and about 300msec to our startup profile.

If we can't kill it for Gecko as a whole, we'd certainly be happy to kill it just for Fennec.
Comment 26 Neil Deakin 2014-03-18 06:16:07 PDT
It isn't hard to remove the hidden window and can be done on all non-Mac platforms fairly easily. Unfortunately, there's been a significant increase in the number of places were people have been using the hidden window. Fortunately, I believe bug 565388 has now given us a way to make hidden documents without the need for the hidden window, so we should be able to convert some of these uses.
Comment 27 Neil Deakin 2014-03-18 06:18:51 PDT
Also bug 846906.
Comment 28 Richard Newman [:rnewman] 2014-03-18 09:21:19 PDT
None of those consumers should be affecting Fennec's startup flow -- we would regard that as a bug -- or perhaps even affecting Fennec at all.

Is it possible to get an updated patch that either rips HW out, or makes it lazy, so we can assess on Fennec regardless of failures?
Comment 29 (Back on May31) Kartikaya Gupta (email:kats@mozilla.com) 2015-04-16 05:51:12 PDT
Android is covered by bug 681733.

Note You need to log in before you can comment on or make changes to this bug.