Last Comment Bug 766871 - Handle window.open in <iframe> within <iframe mozbrowser>
: Handle window.open in <iframe> within <iframe mozbrowser>
Status: RESOLVED FIXED
[qa+]
:
Product: Core
Classification: Components
Component: DOM (show other bugs)
: unspecified
: All All
: -- normal (vote)
: mozilla16
Assigned To: Justin Lebar (not reading bugmail)
:
Mentors:
Depends on: 742944 766481
Blocks: browser-api
  Show dependency treegraph
 
Reported: 2012-06-21 00:04 PDT by Tim Guan-tin Chien [:timdream] (please needinfo)
Modified: 2013-04-04 13:53 PDT (History)
10 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
+
+


Attachments
Patch, v1 (2.11 KB, patch)
2012-06-21 10:37 PDT, Justin Lebar (not reading bugmail)
bzbarsky: review+
Details | Diff | Splinter Review
Tests, v1 (6.41 KB, patch)
2012-06-21 10:37 PDT, Justin Lebar (not reading bugmail)
bzbarsky: review+
Details | Diff | Splinter Review

Description Tim Guan-tin Chien [:timdream] (please needinfo) 2012-06-21 00:04:07 PDT
This is the window.open version of bug 766481.

STR:

Gaia with this pull
https://github.com/mozilla-b2g/gaia/pull/1853
and the last two buttons of window.open test. (naked window.open is not implemented in System app yet)

Expected:

- alert() show up with "Window: [object Window]"
- attention screen pops up, or the background window show itself by issuing alert() (after ~1 sec)

Actual:

- alert() "Window: null" and nothing else.
Comment 1 Justin Lebar (not reading bugmail) 2012-06-21 10:12:42 PDT
I see what's going on here; another stupid bug.
Comment 2 Justin Lebar (not reading bugmail) 2012-06-21 10:37:27 PDT
Created attachment 635367 [details] [diff] [review]
Patch, v1
Comment 3 Justin Lebar (not reading bugmail) 2012-06-21 10:37:38 PDT
Created attachment 635369 [details] [diff] [review]
Tests, v1
Comment 4 Justin Lebar (not reading bugmail) 2012-06-21 10:38:55 PDT
This depends on bug 766481 because the tests use alert() from <iframe> inside <iframe mozbrowser>, which won't work without bug 766481 fixed.
Comment 5 Boris Zbarsky [:bz] 2012-06-21 13:49:24 PDT
Comment on attachment 635367 [details] [diff] [review]
Patch, v1

r=me, I guess
Comment 6 Boris Zbarsky [:bz] 2012-06-21 13:50:18 PDT
Comment on attachment 635369 [details] [diff] [review]
Tests, v1

r=me
Comment 7 Justin Lebar (not reading bugmail) 2012-06-21 13:59:22 PDT
By way of explanation, for posterity:

<jlebar> bz, what's "I guess" for?  :)
<bz> I have no idea whether the code is actually correct.  ;)
<bz> e.g. I have no idea why looking at the .top matters
<jlebar> bz, Oh.  If we don't look at .top, we fire the mozbrowseropenwindow event on the inner <iframe>, not on the <iframe mozbrowser>.
<jlebar> bz, It's not a problem OOP because we never see the <iframe>, only the outer <iframe mozbrowser>.
Comment 9 Jason Smith [:jsmith] 2012-06-26 23:07:50 PDT
Naoki - Could you verify this fix when there's a gaia build containing this patch?

Do we know when this patch (if not already) should be in an otoro build (new to the build process, so I don't know the full details of when mozilla central patches end up in an otoro build)?
Comment 10 Justin Lebar (not reading bugmail) 2012-06-27 01:17:57 PDT
Jason, please find me on IRC sometime and I'll help you figure out how to tell whether a build contains a given changeset.

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