Closed
Bug 1039008
Opened 11 years ago
Closed 11 years ago
URIs in iframes are relative to the iframe origin
Categories
(Core :: DOM: Core & HTML, defect)
Core
DOM: Core & HTML
Tracking
()
RESOLVED
INVALID
People
(Reporter: drs, Unassigned)
Details
Example: http://people.mozilla.org/~dsherk/dialer-docs/keypad.html
The "Callbar" section should have a little phone image on it, but because its outer frame is an iframe, Gecko is trying to access it via the following URI:
chrome://browser/content/devtools/style/dialer/keypad/images/keypad/actionicon_activecall_pickup.png
In Chrome, this works as expected, and the URI gets resolved to the main outer document window's sources.
![]() |
||
Comment 1•11 years ago
|
||
Hold on. Back up.
That iframe has a data: URI. Its base URI is the data: URI itself, no? That's certainly what I see when I examine document.baseURI in that iframe. Where did that chrome:// URI in comment 0 come from?
In Chrome for some reason that document has different base URI, I agree. But in chrome the "src" attribute of the iframe is also totally different. In Chrome it's http://people.mozilla.org/~dsherk/dialer-docs/keypad.html#__preview__ instead of a data: URI.
So what's creating that iframe, and why is it setting different src attributes on it in different browsers? I suspect a much smaller testcase would do wonders here in terms of figuring out what's going on.
Flags: needinfo?(drs+bugzilla)
Reporter | ||
Comment 2•11 years ago
|
||
Thanks, I didn't notice that. I'll make a reduced test case and get back to you.
Reporter | ||
Comment 3•11 years ago
|
||
Yes, this was bogus.
Status: NEW → RESOLVED
Closed: 11 years ago
Flags: needinfo?(drs+bugzilla)
Resolution: --- → INVALID
Assignee | ||
Updated•6 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•