Closed
Bug 577981
Opened 15 years ago
Closed 15 years ago
<iframe> inside of <dialog> behaves differently
Categories
(Core :: XUL, defect)
Tracking
()
VERIFIED
FIXED
Tracking | Status | |
---|---|---|
blocking2.0 | --- | beta3+ |
People
(Reporter: tonglebeak, Unassigned)
References
Details
(Keywords: regression)
Attachments
(1 file)
1.29 KB,
application/zip
|
Details |
Odd problem here. If I load an iframe inside of a dialog, it will work just fine if the type is "chrome." If the type is "content" then it will not load. This problem ONLY happens inside of <dialog>. It does not appear to happen inside of <window>.
This does not happen in 3.6, but does in the beta.
Mozilla/5.0 (X11; Linux x86_64; en-US; rv:2.0b2pre) Gecko/20100711 Gentoo Firefox/4.0b2pre
The testcase attached. Open "testcase.xul." You'll see a <window> with two iframes that are behaving as expected. Open the dialog by clicking the button, and you'll see the exact same iframes, behave differently. The blank is content, the visible is chrome.
Reporter | ||
Updated•15 years ago
|
Component: General → XUL
Product: Firefox → Core
QA Contact: general → xptoolkit.widgets
Comment 1•15 years ago
|
||
Aaron, would you have time to use nightlies to hunt down when the behavior changed here?
Reporter | ||
Comment 2•15 years ago
|
||
Phew, I can try. The binaries don't like to run on my gentoo system though. Will report back.
Reporter | ||
Comment 3•15 years ago
|
||
Looks like it breaks between 6-28 and 6-29
Comment 4•15 years ago
|
||
Aaron, what are the build ids (from about:buildconfig) for those two builds?
Reporter | ||
Comment 5•15 years ago
|
||
I hope this is what you're looking for...
http://hg.mozilla.org/projects/electrolysis/rev/a8fa5480651a - 0629
http://hg.mozilla.org/projects/electrolysis/rev/8e4ceb3b4da5 - 0628
Comment 6•15 years ago
|
||
Yep, that's exactly it. Changes made between those builds:
http://hg.mozilla.org/projects/electrolysis/pushloghtml?fromchange=8e4ceb3b4da5&tochange=a8fa5480651a
Unfortunately, those are electrolysis branch builds, so all that really tells us is that something in those merges from mozilla-central caused the problem. Aaron, can you try mozilla-central nightlies?
Reporter | ||
Comment 7•15 years ago
|
||
Between 6-27 and 6-28
http://hg.mozilla.org/mozilla-central/rev/9c85f9aaec8c - 0628
http://hg.mozilla.org/mozilla-central/rev/6b36b6da79bd - 0627
Reporter | ||
Updated•15 years ago
|
blocking2.0: --- → ?
Comment 8•15 years ago
|
||
Checkin range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6b36b6da79bd&tochange=9c85f9aaec8c
My money is on bug 574690.
Blocks: 574690
Keywords: regression
Reporter | ||
Comment 9•15 years ago
|
||
Yup, that's it. I cloned the repo, built and still confirmed the problem was there. Backed-out 7ad36412775e and the problem is gone.
Comment 10•15 years ago
|
||
resolved by the backout in bug 574690.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Reporter | ||
Updated•14 years ago
|
Status: RESOLVED → VERIFIED
blocking2.0: ? → beta3+
You need to log in
before you can comment on or make changes to this bug.
Description
•