Closed Bug 83576 Opened 25 years ago Closed 23 years ago

file:// pages containing file:// IFRAME loaded don't fire onload, don't reload iframe content when changed

Categories

(Core :: Layout: Images, Video, and HTML Frames, defect)

Product:
Core
Component:
Layout: Images, Video, and HTML Frames
Platform:
x86
Windows 98
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Future

People

(Reporter: vladimire, Assigned: john)

References

Details

(Keywords: testcase)

Attachments

(3 files)

the bug localization
136 bytes, text/html
Details
Another test to demonstrate this bug
507 bytes, text/html
Details
Another test to demonstrate this bug (file 2)
91 bytes, text/html
Details
If you open a page with an IFRAME from your hard drive the IFRAME does not load it's conent, no matter local or global. Sometimes it does, but it behaves differently then when uploaded. For example if you have a onload event handler it works from server, but not from FILE://. This is a pain in the ass for developers if they want to test how their page looks during the design process. To reproduce create a file with content that looks something like this: <HTML> <HEAD> <TITLE></TITLE> </HEAD> <BODY> <IFRAME onload="alert('test');" src="page1.html"> </IFRAME> </BODY> </HTML> and another page1.html: <HTML><HEAD><TITLE></TITLE></HEAD> <BODY>Page1</BODY> </HTML> try opening the first file and see if anything shows up in the IFRAME. If the page does show up, go back and edit the code change src to some other url, www.yahoo.com for example. Reload the page, and it is still showing page1 or nothing at all.
-> better component
Assignee: asa → pollmann
Component: Browser-General → HTMLFrames
QA Contact: doronr → amar
So, this sounds like three problems: 1) <iframe src="file://..."> does not load content 2) <iframe onload="..." src="file://..."> does not fire onload 3) if the outer document is a file:// url, clicking reload will leave the old page showing in the iframe I could not reproduce 1) 2) may be bug 82458 or a related problem, cc'ing Rick 3) may be session history, may be cache, ??? cc'ing Radha
Status: NEW → ASSIGNED
After editing the page, when you do a simple reload, the page is loaded from the cache, which would have the older content. You have to press shift-reload to bypass the cache and fetch the edited copy from the file. Did you see the problem with shift-reload too?
yes
i'm confused. the files inlined in the description don't seem to be what is described later. what is described later: <iframe src="file:///c%7C/autoexec.bat"> is prohibited by our security model.
You may be on to something! <iframe src="file:///c%7c/autoexec.bat"> is prohibited from loading the file iff the page *containing* the iframe is not a file:// URL. I had assumed that the first sentence ".. a page with an IFRAME from your hard drive..." meant the *page* was from your hard drive, but if in fact the reporter meant that the *IFRAME* was from your hard drive, but the page is not, than your suspicions are correct. We are not, and should not, be loading the content of the IFRAME. I'm going to assume that this is the case, and 1) is not a bug. Still, we have problems 2) and 3). To be clear, let's assume both the containing page and the iframe inside of it come from file:// urls - 2) and 3) are both still present and bugs.
Summary: Pages containing IFRAME loaded with FILE protocol behaves differently then on the server → file:// pages containing file:// IFRAME loaded don't fire onload, don't reload iframe content when changed
Should not be a problem for typical users, pushing to Future... (Let me know if you feel this is a bad decision)
Target Milestone: --- → Future
I noticed the behaviour on an ordinary HTML page and localized the source. In the attachment you find a page that contains nothing, but imports a CSS style. The browser never completes loading of the page when using "file:///", and that even if the link refers to an existing stylesheet file. I have WinNT SP6, Mozilla build 20010613.
Attached file the bug localization —
Bulk reassignin HTML FRAME/IFRAME bugs to Eric.
Assignee: pollmann → evaughan
Status: ASSIGNED → NEW
Another more comprehensive test.
The frame contents
WINGE ----- I just got screwed by this bug too for a few hours ... I was going through the process of documenting the it when i found this one ... COMMENTS ON PRIOR COMMENTS -------------------------- I have never had any trouble with actually loading, rendering or refreshing the content in the iframes, but I have had trouble subsequently accessing an iframe being rendered from a local file (local to the iframe source). ATTACHMENTS ----------- I have attached two files, one as the IFRAME creator and another as the iframe contents. Change the server name and directory in iframebugtest.htm and render iframebugtest.htm both locally and on a server. PROBLEM DEFINITION ------------------ A locally loaded IFRAME doesnt appear to be put through the same amount of processing as a remotely loaded IFRAME. That is, a locally loaded IFRAME cant be accessed at all through JavaScript. TEST CASE --------- See attachments 'Another test to demonstrate this bug' and 'Another test to demonstrate this bug (file 2)'. Change the server name and directory in iframebugtest.htm and render iframebugtest.htm both locally and on a server. EXPECTED RESULTS ---------------- LOCALLY RENDERED: Local Pane: notification of onload event processing & red background set for IFRAME Remote Pane: notification of onload event processing & unchanged background (due to access restrictions of not being able to access frames from different domains) SERVER RENDERED: Local Pane: notification of onload event processing & red background set for IFRAME Remote Pane: notification of onload event processing & red background set for IFRAME ACTUAL RESULTS -------------- LOCALLY RENDERED: Local Pane: NO NOTIFICATION OF ONLOAD & NO RED BACKGROUND SET FOR IFRAME [*FAIL*] Remote Pane: notification of onload event processing & unchanged background (due to access restrictions of not being able to access frames from different domains) [PASS] SERVER RENDERED: Local Pane: notification of onload event processing & red background set for IFRAME [PASS] Remote Pane: notification of onload event processing & red background set for IFRAME [PASS] MY THEORY --------- I know nothing of the Mozilla codebase, however the problem seems to be that a frame must go through HTTP processing to become a frame proper. That is, the rendering of a frame and its establishment in script seem to be two separate things. Rendering the frame works fine. It appears that the 'establish the frame for JavaScript use' code has been erroneously placed in the comms code - it should be in a broader section of the browser ... one that doesnt distinguish between http:// and file://. Hopefully this bug wont be too hard to fix ... it might be as simple as moving a function call or adding another one to the file:// processing code... ?
Bulk re-assigning all of Eric's HTMLFrame bugs to John.
Assignee: eric → jkeiser
This should be fixed by my iframe loading changes in bug 52334.
Depends on: 52334
i believe this is somewhat related to bug #122150.
QA Contact: amar → vladimire
adding testcase keyword in order to remove from BugAThon testcase needed list. (seems it has them already)
Keywords: testcase
WFM on trunk, JST's iframe change appears to have fixed it. (1.1 should have the change too.)
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
verifying. win2k 2002-09-10-08-trunk
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
Component: Layout: HTML Frames → Layout: Images
Product: Core Graveyard → Core

I have an iframe in a form (in a local Intranet). If I change the content of a file and then click on a butto to load a Fancybox iframe, then form display the old file cached not the modified file...
If J delete the cache it display normally the modified file... Then it is firefo that don't display the new version of a modified file...
This is important because the modified fiel file is a invoice (in Italy)... and I am cosctrict to delete cache before sending file to
tanks a lot to search this bug
email manarolla.vincenzo@euro1.it

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

Attachment

General

Creator:
Created:
Updated:
Size: