The default bug view has changed. See this FAQ.

Handle window.open in <iframe> within <iframe mozbrowser>

RESOLVED FIXED in mozilla16

Status

()

Core
DOM
RESOLVED FIXED
5 years ago
4 years ago

People

(Reporter: timdream, Assigned: Justin Lebar (not reading bugmail))

Tracking

(Blocks: 1 bug)

unspecified
mozilla16
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking-kilimanjaro:+, blocking-basecamp:+)

Details

(Whiteboard: [qa+])

Attachments

(2 attachments)

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.
(Assignee)

Comment 1

5 years ago
I see what's going on here; another stupid bug.
Assignee: nobody → justin.lebar+bug
Status: NEW → ASSIGNED
Component: General → DOM: Mozilla Extensions
Product: Boot2Gecko → Core
QA Contact: general → general
(Assignee)

Comment 2

5 years ago
Created attachment 635367 [details] [diff] [review]
Patch, v1
Attachment #635367 - Flags: review?(bzbarsky)
(Assignee)

Comment 3

5 years ago
Created attachment 635369 [details] [diff] [review]
Tests, v1
Attachment #635369 - Flags: review?(bzbarsky)
(Assignee)

Comment 4

5 years ago
This depends on bug 766481 because the tests use alert() from <iframe> inside <iframe mozbrowser>, which won't work without bug 766481 fixed.
Depends on: 766481
Comment on attachment 635367 [details] [diff] [review]
Patch, v1

r=me, I guess
Attachment #635367 - Flags: review?(bzbarsky) → review+
Comment on attachment 635369 [details] [diff] [review]
Tests, v1

r=me
Attachment #635369 - Flags: review?(bzbarsky) → review+
(Assignee)

Comment 7

5 years ago
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>.
https://hg.mozilla.org/mozilla-central/rev/6838f7908bda
https://hg.mozilla.org/mozilla-central/rev/633a85b28dbb
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla16
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)?
Whiteboard: [qa+]
(Assignee)

Comment 10

5 years ago
Jason, please find me on IRC sometime and I'll help you figure out how to tell whether a build contains a given changeset.

Updated

5 years ago
Blocks: 693515
No longer depends on: 693515
Component: DOM: Mozilla Extensions → DOM
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.