Open Bug 301198 Opened 19 years ago Updated 2 years ago

Firefox never send a request for the frame named mainFrame.

Categories

(Core :: DOM: Core & HTML, defect, P5)

Product:
Core
Component:
DOM: Core & HTML
Type:
defect

Tracking

()

People

(Reporter: ludberg, Unassigned)

References

(
URL
)

Details

(Keywords: testcase)

Attachments

(1 file)

minimal testcase
840 bytes, application/zip
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.9) Gecko/20050711 Firefox/1.0.5 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.9) Gecko/20050711 Firefox/1.0.5 The mainframe (named 'mainFrame') is not loaded at all. <frame src="p/main.html" name="mainFrame"> Infact Firefox sometimes don't send a request. I have tried with and without cache enabled. Rather of displaying the content - Firefox displays about:blank. The same problem occur with version 1.0.4. Reproducible: Sometimes Steps to Reproduce: 1. Just load the page. 2. 3. Actual Results: No mainFrame is displayed Expected Results: Displayed the mainframe
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050718 Firefox/1.0+ ID:2005071812 mainFrame shows up find for me on that page. Could you try this with one of the latest builds? http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050718 Firefox/1.0+ To reproduce this bug do the following. 1. Go to the mainpage (http://www.bilddagboken.se) 2. Click on one of the thumbnails at the bottom. 3. Go back to the mainpage (click the logo in the top left corner) 4. Click the same picture again. Try login with user: test and password: test The problem seems to reproduce only when you're logged in. The mainFrame has the same URL and if you paste the frame URL into the addressbar the frame shows up.
I see this in trunk, too. However, I do not see it with bfcache disabled. *** This bug has been marked as a duplicate of 300944 ***
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
I very much doubt that this is related to bfcache, since Firefox 1.0.x does not support bfcache. And I see this in Firefox 1.0.3 as well, if I am logged in and JavaScript is enabled. However, it works for me if JS is disabled. This leads me to believe that the effect is caused by the following JavaScript code in the HEAD of the top frame (which is not present when not logged in): <script> window.top.mainFrame.location.reload(); </script> I guess that occasionally the URL of "mainFrame" is still undefined when the reload is triggered.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Confirming and reassigning to Core/DOM Lvl 0 for further evaluation (I'm not sure whether this is actually a bug or just some undefined behaviour).
Assignee: nobody → general
Status: UNCONFIRMED → NEW
Component: General → DOM: Level 0
Ever confirmed: true
Product: Firefox → Core
QA Contact: general → ian
Version: unspecified → Trunk
Elmar Ludwig was right. When the script was removed from <head> the page loaded just fine. Thanks.
So how do I reproduce the bug? If the site needs a login, can someone please attach a no-login-required testcase to this bug?
When the bug was reported, it only happened when logged into the site, see my remark in comment 4. The Login/Paswort given in comment 2 still works, but the reporter has since then removed the JS code that caused the problem, so you won't see any problems now... I will try to reconstruct a minimal testcase today.
Attached file minimal testcase —
Testcase (ZIP archive) containing three files. Steps to reproduce: 1. extract files from archive 2. open 301198/index.html I see the following behaviour (Firefox 1.5rc1 on Linux): On initial loading, the top frame displays fine, but the lower frame remains empty. "View Frame Info" reports "about:blank" as address, not "main.html". Reloading the frameset sometimes (but not always) displays the lower frame. Shift-Reload consistently only shows the top frame. If JS is disabled, both frames load fine.
Severity: major → normal
Keywords: testcase
OS: Windows XP → All
Hardware: PC → All
That's a good question. What should reload() do for a document that's started a load of a new document but hasn't heard back from the server yet? Right now we reload the _current_ document.
Assignee: general → nobody
QA Contact: ian → general
https://bugzilla.mozilla.org/show_bug.cgi?id=1472046 Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5. If you have questions, please contact :mdaly.
Priority: -- → P5
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: