Closed Bug 810431 Opened 12 years ago Closed 6 years ago

Browser API: frame launched with window.open does not come with setVisible() method

Categories

(Firefox OS Graveyard :: General, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: timdream, Unassigned)

References

Details

When working on bug 808227, error thrown when attempting to setVisible() on wrapper frames (i.e. frame launch with window.open() in home screen app and created in mozbrowseropenwindow event).

[JavaScript Error: "TypeError: openFrame.setVisible is not a function" {file: "app://system.gaiamobile.org/js/window_manager.js" line: 627}]

Justin said this should be a bug. Taking, I would to find out what happened in browserElementChild.js first.
Justin,

I enabled the debug() in BrowserElementParent.js and add some code in the openWindow() method in the window_manager.js, this is what I found:

I/GeckoDump( 1809): WindowManager - setVisible not exists
I/Gecko   ( 1809): BrowserElementParent - Remote browser frame shown [xpconnect wrapped nsIFrameLoader]
I/Gecko   ( 1809): BrowserElementParent - Creating new BrowserElementParent object for [xpconnect wrapped nsIFrameLoader]
I/Gecko   ( 1809): BrowserElementParent - Creating new BrowserElementParent object done
I/GeckoDump( 1809): WindowManager - setVisible exists

It looks like mozbrowser is not initialized at the time frameElement is passed to the web content.
Assignee: timdream+bugs → nobody
Flags: needinfo?(justin.lebar+bug)
> I enabled the debug() in BrowserElementParent.js and add some code in the openWindow() 
> method in the window_manager.js, this is what I found:

Do you still have your patch sitting around so I can test this locally?
Flags: needinfo?(justin.lebar+bug)
(In reply to Justin Lebar [:jlebar] from comment #2)
> > I enabled the debug() in BrowserElementParent.js and add some code in the openWindow() 
> > method in the window_manager.js, this is what I found:
> 
> Do you still have your patch sitting around so I can test this locally?

I don't have it anymore, but I can redo it if that would save you some time.
Oh, I think I know what's happening.

Under normal circumstances, BEP and BEC (BrowserElementParent/Child) don't get loaded until the iframe is inserted into the DOM.

window.open() is a little bit funky -- we force the BEC to load earlier than it would otherwise, since the opener synchronously gets a copy of the opened window -- but we don't do anything to force BEP to get loaded earlier, afaict.  You have to insert the frame into the DOM and spin the event loop if you want setVisible() (and the other methods).

I agree this is a bug, but can you work around it, e.g. with a setTimeout(0)?  I'm becoming convinced that the right solution is to have a separate element (e.g. <webview>) which always has these methods.
(In reply to Justin Lebar [:jlebar] from comment #4)
> I agree this is a bug, but can you work around it, e.g. with a
> setTimeout(0)?  I'm becoming convinced that the right solution is to have a
> separate element (e.g. <webview>) which always has these methods.

Yes, this bug is workaround-able. That's why it didn't receive a bb? nomination.
I think we are now cache the browser API method in gecko even we don't have them yet so any call to browser iframe is safe, shall we close this bug?
Flags: needinfo?(timdream)
Yes, I think so. Although I am not sure which bug actually fix this.
Flags: needinfo?(timdream)
Patrick could you confirm bug 960641 fixed this one as well? Thanks.
Flags: needinfo?(kk1fff)
Bug 960641 attaches browser APIs onto an iframe element synchronously, no matter the new content process has been created or not, it should fix bugs like this.
Flags: needinfo?(kk1fff)
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.