1270790 - Chrome <iframe mozbrowser> cannot load http/https sources

Status: RESOLVED WONTFIX

(Core :: DOM: Core & HTML, defect)

Description

[:gerard-majax]

STR:
 0. Move mochitest to chrome mochitest
 1. <iframe mozbrowser>.src = "http://example.org/"

Expected:
 Page loads and we get load event

Actual:
 Page does not load and we get no load event.

Change <iframe mozbrowser>.src to some valid chrome:// URL and it works. Set the iframe as remote with "remote=true" and it works.

Comment 1

[:gerard-majax]

Attachment: <iframe mozbrower> load event triggering

This simple test exposes the issue.

Comment 2

[:gerard-majax]

It looks like it even sometimes does only work from chrome with the mozbrowserloadend event, not load.

Comment 3

[:gerard-majax]

Attachment: <iframe mozbrower> load event triggering

MozReview-Commit-ID: FyLboKvrLWd

Comment 4

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

Comment on attachment 8749594 [details] [diff] [review]
<iframe mozbrower> load event triggering

I am not a mozbrowser peer, so let's check with :kanru.

I'll keep thinking about the problem as well.

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

So does <iframe mozbrowser> when used in chrome create right kind of docshell?

Comment 6

[:gerard-majax]

(In reply to Olli Pettay [:smaug] from comment #5)
> So does <iframe mozbrowser> when used in chrome create right kind of
> docshell?

How to check this? Compare the docshell object between an <iframe mozbrowser> used from chrome against one used from content? Any specific property to check against?

Comment 7

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

(In reply to Olli Pettay [:smaug] from comment #5)
> So does <iframe mozbrowser> when used in chrome create right kind of
> docshell?

From reading the code, <iframe mozbrowser> always creates content docshells[1]:

  // Force mozbrowser frames to always be typeContent, even if the
  // mozbrowser interfaces are disabled.
  nsCOMPtr<nsIDOMMozBrowserFrame> mozbrowser =
    do_QueryInterface(mOwnerContent);
  if (mozbrowser) {
    bool isMozbrowser = false;
    mozbrowser->GetMozbrowser(&isMozbrowser);
    isContent |= isMozbrowser;
  }

[1]: https://dxr.mozilla.org/mozilla-central/rev/e5a10bc7dac4ee2453d8319165c1f6578203eac7/dom/base/nsFrameLoader.cpp#562-570

Comment 8

[Olli Pettay [:smaug][[e-mail]]]

That is good. I consider it a bug that xul:browser defaults to chrome docshell.

Note, load event dispatching is different when crossing chrome boundary. the xul:browser/html:iframe in the boundary does _not_ get its own load event, but the load event propagates from the window object in side the sub-frame to the xul:browser/html:iframe. One needs to use capturing listener to catch it. This all in non-remote case of course.

But I have no idea about page not loading issue here.

Comment 9

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

:gerard-majax, can you capture the load event with a capturing listener, `addEventListener("load", handler, true)`?

In a recent test case I wrote, I used a frame script to listen for load in the child, and then sent a message back up to the parent with the message manager, as that seemed to be the most stable way to detect it.  That may be another option here.

Comment 10

[:gerard-majax]

(In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #9)
> :gerard-majax, can you capture the load event with a capturing listener,
> `addEventListener("load", handler, true)`?
> 
> In a recent test case I wrote, I used a frame script to listen for load in
> the child, and then sent a message back up to the parent with the message
> manager, as that seemed to be the most stable way to detect it.  That may be
> another option here.

no, changing the addEventListener() does nothing.