Recent changes for e10s creates a hidden window that is not completely hidden

RESOLVED FIXED in 1.4

Status

Add-on SDK
General
P1
normal
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: zer0, Assigned: irakli)

Tracking

({regression})

unspecified
x86
Mac OS X
regression

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

6 years ago
Created attachment 572022 [details]
OS X Window menu

The recent Module Loader changes for e10s creates a hidden window in order to load a XUL <browser> tag. Unfortunately, on Mac OS X (both Snow Leopard and Lion) this window is not totally hidden, it's shown in the Window menu as a "blank titled" window (see attachment).

The code in subject should be this one:

https://github.com/mozilla/addon-sdk/blob/master/packages/api-utils/lib/window-utils.js#L219
(Reporter)

Updated

6 years ago
Keywords: regression
(Reporter)

Comment 1

6 years ago
I experienced some weird behavior when an add-on built with this "hidden window" is running, sometimes Firefox and Thunderbird just "hang on", I guess because is related to some window managing stuff, but I wasn't able to reproduce always the steps. If I disabled the add-ons, or I use the same add-ons made with the previous version of SDK, I don't have such problems.
Assignee: nobody → rFobic
pasting conversation from IRC:

ochameau
The code that create the hidden window lives here:
12:22
http://mxr.mozilla.org/mozilla-central/source/xpfe/appshell/src/nsAppShellService.cpp#114
12:22
there may be some hints
12:27ochameau
gozala: by reading this source code, it may be simple ... appShellService::CreateTopLevelWindow  can be called from JS
12:28
gozala: and if you pass aChromeMask argument set to 0, it seems that you will have mostly was CreateHiddenWindow does!
(Reporter)

Comment 3

6 years ago
A reproducible side effect is the follow: if the user close the last "visible" window, when he clicked again on the executable of Firefox / Thunderbird, a new window is NOT opened as it supposed to be. That's because the window's count is not 0, so the application just give the focus back to the current window (that is the hidden one).
Created attachment 573030 [details]
Pointer to Github pull request: https://github.com/mozilla/addon-sdk/pull/256/files

Pointer to Github pull-request
Attachment #573030 - Flags: review?(poirot.alex)
(In reply to Irakli Gozilalishvili [:irakli] [:gozala] from comment #2)
> pasting conversation from IRC:
> 
> ochameau
> The code that create the hidden window lives here:
> 12:22
> http://mxr.mozilla.org/mozilla-central/source/xpfe/appshell/src/
> nsAppShellService.cpp#114
> 12:22
> there may be some hints
> 12:27ochameau
> gozala: by reading this source code, it may be simple ...
> appShellService::CreateTopLevelWindow  can be called from JS
> 12:28
> gozala: and if you pass aChromeMask argument set to 0, it seems that you
> will have mostly was CreateHiddenWindow does!

I have tried to use `nsIAppShellService.createTopLevelWindow`
https://developer.mozilla.org/En/NsIAppShellService#createTopLevelWindow%28%29

but for some reason window always had an HTM document instead of expected XUL. In the end I decide to implement slightly different approach. Also even with `createTopLevelWindow` and `aChromeMask` 0 window still was showing up in window list and `unregisterTopLevelWindow` was required anyway.
Comment on attachment 573030 [details]
Pointer to Github pull request: https://github.com/mozilla/addon-sdk/pull/256/files

One problem is fixed. The hidden windows isn't displayed in windows list anymore,
but it still block firefox from quitting when you close the last browser window.

Simple way to test this is to go to an example and run: cfx run
Then when you close firefox window, cfx should quit.

Otherwise, if you build another patch, keep in mind to remove unused code: getDOMWindow method.
Attachment #573030 - Flags: review?(poirot.alex) → review-
Comment on attachment 573030 [details]
Pointer to Github pull request: https://github.com/mozilla/addon-sdk/pull/256/files

So I tried multiple approaches, including one that was making custom hidden window being a child of app hidden window:
https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsIXULWindow#addChildWindow%28%29

This solved issue on linux, but introduce some other strange behavior on OSX. In the end I decided to don't open any windows at all and used iframe with xul document in it for plaforms where hidden window is not a XUL document.

This seems to behave as expected on mac and linux. I have not win environment setup, so maybe @ochameau you could verify that it behaves there as expected.
Attachment #573030 - Flags: review- → review?(poirot.alex)
Comment on attachment 573030 [details]
Pointer to Github pull request: https://github.com/mozilla/addon-sdk/pull/256/files

Works fine on Windows too! cfx testall is green.

I've added some minor nits in the pull request.
Attachment #573030 - Flags: review?(poirot.alex) → review+

Updated

6 years ago
Priority: -- → P1
Target Milestone: --- → 1.4
https://github.com/mozilla/addon-sdk/commit/7726ce7477cb45cca7131395bb1614af09b26809
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.