Open
Bug 686235
Opened 14 years ago
Updated 3 years ago
Images in iframes added dynamically are painted as broken after restart with session restore
Categories
(Firefox :: Session Restore, defect)
Tracking
()
NEW
People
(Reporter: mayhemer, Unassigned)
Details
Attachments
(1 file)
|
566 bytes,
application/zip
|
Details |
See the test case (just unpack the archive, index.html loaded as a local file is enough to reproduce, no need for a server).
STR: Simply load the page, set Firefox to remember open windows, close it and start again.
Result: The small image in the iframe will be shown as broken. The request for it is never made, until I hit Ctrl-F5!
This is very old bug, I wanted to report it at least a year ago since I was experiencing it since the old 3.0 branch. I confirmed this is reproducible since 3.6.22 till current mozilla-central.
In the log I can see following errors when I pres just F5:
2011-09-11 21:59:38.655000 UTC - 0[32c7f8]: WARNING: Subdocument container has no frame: file c:/Mozilla/src/mozilla-central/layout/base/nsDocumentViewer.cpp, line 2422
2011-09-11 21:59:38.671000 UTC - 0[32c7f8]: WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x804B000A: file c:/Mozilla/src/mozilla-central/content/base/src/nsImageLoadingContent.cpp, line 632
[1], nsImageLoadingContent::StringToURI fails because |baseURI| is nsNestedAboutURI and not the document URI. aSpec is in this case just a relative URI.
Preview of the code to reproduce:
<!DOCTYPE html>
<html>
<head>
<script>
/*
Body of this page has an empty (src="") iframe.
It is filled with a simple html (innerHTML) with an image inside.
After restart, the image is displayed as broken.
*/
function test()
{
var frm = document.getElementById("_frm");
frm.contentDocument.body.innerHTML =
"<html><body><img src='some.gif' /></body></html>";
}
</script>
</head>
<body onload="test()">
<iframe src="" id="_frm"></iframe>
</body>
</html>
[1] http://hg.mozilla.org/mozilla-central/annotate/b384cfab8b1d/content/base/src/nsImageLoadingContent.cpp#l871
|
||
Comment 1•14 years ago
|
||
So the point is that the dynamically added iframe has the wrong base URI after restore, right?
Right now, the base URI of an about: document is set via the baseURI channel property. And this is set from the base URI used to resolve the about: URI.
Unfortunately, I expect session restore doesn't go through loading APIs that take an nsIURI, right?
|
|
Reporter | |
Comment 2•14 years ago
|
||
(In reply to Boris Zbarsky (:bz) from comment #1)
> So the point is that the dynamically added iframe has the wrong base URI
> after restore, right?
Exactly.
>
> Right now, the base URI of an about: document is set via the baseURI channel
> property. And this is set from the base URI used to resolve the about: URI.
>
> Unfortunately, I expect session restore doesn't go through loading APIs that
> take an nsIURI, right?
I don't know this code very well, what exactly should I look for?
|
|
||
Comment 3•14 years ago
|
||
How exactly does session restore load its subframes?
|
|
||
Comment 4•14 years ago
|
||
Actually, the best thing to look for is what session restore does with nsIPrincipals it deserializes from the session data. Presumably those get passed to the subframe loads somehow.
|
|
Reporter | |
Comment 5•14 years ago
|
||
I think this falls to my "later" list. But it annoys me because it breaks my web app, so I'll try to give it some effort.
|
||
Updated•3 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•