Closed Bug 56062 Opened 24 years ago Closed 24 years ago

back/forward buttons don't work at first if first page is framed

Categories

(Core :: DOM: Navigation, defect, P1)

Product:
Core
Component:
DOM: Navigation
Platform:
x86
All
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.1

People

(Reporter: target, Assigned: radha)

References

(
URL
)

Details

(Keywords: dataloss, testcase, Whiteboard: [nsbeta1+])

Attachments

(2 files)

Frame testcase - open in a new window
212 bytes, text/html
Details
patch to docloader
533 bytes, patch
Details | Diff | Splinter Review
If the first site you go to after loading mozilla is in frames, the back and forward buttons remain greyed out while navigating it. They will only activate if you go to a non-framed site first, or leave the framed site for another site & come back. I think mozilla's assuming that there's nowhere to go because the parent page containing the frames doesn't appear to change. It's odd how it drops this assumption and begins behaving properly again under the aforementionned circumstances though.
Marking verified w/ 2000101008 Win2k. Changing component to Browser::History.
Status: UNCONFIRMED → NEW
Component: Themes → History
Ever confirmed: true
Sending to History
Assignee: hangas → radha
QA Contact: pmac → claudius
Noticed that this also means that no matter how far you browse by links, or even from chrome (like the Mozilla button, etc.) there is no back button.
This is because, notifications to OnLocationChange() in nsBrowserInstance.cpp (which in turn enables/disables the back, forward button) don't happen for a frame page load. If you look in the Go menu, you will see the frame page navigations you did and can go back/forward using that. Cc'ing mscott, law. This belongs to one of them. First trying mscott.
Assignee: radha → mscott
This sounds very similar to bug 56625
*** Bug 56625 has been marked as a duplicate of this bug. ***
Blocks: 59387
URL: http://home.earthlink.net/~jsteenhage...
OS: Windows 98 → All
Bringing URL, dependencies and OS over from 56625
*** Bug 49000 has been marked as a duplicate of this bug. ***
*** Bug 55210 has been marked as a duplicate of this bug. ***
*** Bug 59979 has been marked as a duplicate of this bug. ***
Adding keywords
Keywords: correctness, mostfreq, testcase
*** Bug 60138 has been marked as a duplicate of this bug. ***
*** Bug 56930 has been marked as a duplicate of this bug. ***
De-mostfrequing because the meta bug is mostfreq. Gerv
Keywords: mostfreq
*** Bug 60906 has been marked as a duplicate of this bug. ***
*** Bug 61315 has been marked as a duplicate of this bug. ***
*** Bug 61446 has been marked as a duplicate of this bug. ***
*** Bug 61817 has been marked as a duplicate of this bug. ***
nav triage team: yes this is an important bug for the next release. upping priority.
Keywords: nsbeta1
Priority: P3 → P1
*** Bug 63593 has been marked as a duplicate of this bug. ***
Adding self to CC.
*** Bug 64057 has been marked as a duplicate of this bug. ***
*** Bug 64891 has been marked as a duplicate of this bug. ***
nav triage team: Marking nsbeta1+
Whiteboard: nsbeta1+
*** Bug 67031 has been marked as a duplicate of this bug. ***
This is certainly mostfreq
Keywords: mostfreq
scott, any chance this will get into mozilla0.8 or 0.9? can someone from my team help? thanks, Vishy
The broken history.back issue (#57403) most likely depends heavily on this bug
*** Bug 68527 has been marked as a duplicate of this bug. ***
*** Bug 68527 has been marked as a duplicate of this bug. ***
*** Bug 67685 has been marked as a duplicate of this bug. ***
*** Bug 67685 has been marked as a duplicate of this bug. ***
*** Bug 69207 has been marked as a duplicate of this bug. ***
cc'ing self on this one...
*** Bug 69581 has been marked as a duplicate of this bug. ***
*** Bug 69206 has been marked as a duplicate of this bug. ***
*** Bug 67585 has been marked as a duplicate of this bug. ***
Whiteboard: nsbeta1+ → [nsbeta1+]
Target Milestone: --- → mozilla0.9
adding nsbeta1+ per putterman's comments.
Keywords: nsbeta1 → nsbeta1+
*** Bug 71925 has been marked as a duplicate of this bug. ***
*** Bug 72486 has been marked as a duplicate of this bug. ***
*** Bug 72809 has been marked as a duplicate of this bug. ***
*** Bug 73338 has been marked as a duplicate of this bug. ***
I have a bug that is quite similar, so I file it here. When using the back and forward buttons (not grayed out), the pages dont change sometimes. Sometimes even the browser window itself nearly locks up (mouse cursor remains in the shape that it gets when it is moved over a link) and mozilla doesnt react when clicking on a link in the browser window. After hitting the reload button or manually typing a new adres everything is fine again. All this behaviour was recognized surfing www.kostenlos.de only. Sorry, if this if somewhat unspecific, but I dont know better. I was using: Mozilla/5.0 (Windows; U; Win95; en-US; 0.8.1) Gecko/20010323
moving to mozilla0.9.1
Target Milestone: mozilla0.9 → mozilla0.9.1
Does this bug effect Iframes too? currently, if you have a page with an Iframe with a link in it and you click that link to open a new page within the Iframe, the, if you right click the back and forward options are disabled. You should be able to go back and forward inside an Iframe. Jake
Duplicated behavior in 20010505 Win98. Note that the context menu "back" option is also disabled. I wonder what would happen if a JavaScript called history.back()...
<rant> This is, presumably an easy bug to if as it only involves making sure a flag is set to the correct value. (I haven't taken a look at the code because I don't know C). It has been marked nsbeta1+ for several months It has 21 votes It is a mostfreq It is nsCatFood And I have just added dataloss to the keywords, because I could be filling in a form, click submit and the script generates an error telling me to go back to fix my form, obviously I can't do this. So, why is it not even assigned to anyone? </rant>
Keywords: dataloss
Mozilla team, you should either accept this, or mark helpwanted.
Adding keyword...this is worse then it seems, when opening manuals for such programs as Photoshop Dreamweaver to name a few, the first page is framed and therefore the Back & Forward buttons become useless..this makes the Manuals themselves basically useless. I would suspect opening any local configuration programs on Linux that use frames in HTML as an interface would be useless as well..Just started thinking about this one today when i ran across it again.
Keywords: mozilla0.9.1
-> radha
Assignee: mscott → radha
I will look at this for 0.9.1
Status: NEW → ASSIGNED
looks good to me. thanks radha. r/sr=mscott
r=adamlock
fix checked in
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Fix works for me. But why does it change the URL in the location bar? That usually doesn't happen on framed pages.
Yep, I see the same thing with build 2001051820 on Win2k (SP2) Starting from the page in the URL field above: http://home.earthlink.net/~jsteenhagen/mozilla/56625/ and clicking on the bottom link on that page, I get the following behavior... IE5.5 opens the new window as: http://home.earthlink.net/~jsteenhagen/mozilla/56625/frame.html The URL in the Address bar never changes Mozilla opens the new window as: http://home.earthlink.net/~jsteenhagen/mozilla/56625/frame.html THEN http://home.earthlink.net/~jsteenhagen/mozilla/56625/top.html THEN http://home.earthlink.net/~jsteenhagen/mozilla/56625/main.html The URL in the Address bar switches through each of these pages as they load. Traditionallly, the Address bar would not change at all from the original framed page. The pages loading inside the frameset would load silently (at least as far as the Address bar is concerned). Should this be filed as another bug or should this one be reopened??? Jake
Bug for URL of frames being displayed in location bar is bug 81769.
Bug 82961 looks like this one rised from the dead (or very close). I am neither confirming it nor marking a dup but someone could be interested in looking into it.
*** Bug 79570 has been marked as a duplicate of this bug. ***
*** Bug 82961 has been marked as a duplicate of this bug. ***
VERFIED Fixed with 2001053108 builds on all platforms
Status: RESOLVED → VERIFIED
Not sure if this is the correct bug for this since back button isnt greyed out -- it just wont cause the desired effect. Tried with build 2001053121/linux and 2001053120/WinNT: When opening a frameset web site (http://www.derstandard.at), clicking a link in the center frame that changes that center frame the back button will not work properly: it is not greyed out, but pressing it wont change anything. This can be repeated a few times or forever. Sometimes, after a few times the browser will show an ancestor of the previous page, but never the previous page. This occurs extremely rarely with windows/2001053120 but on linux/build2001053121 nearly everytime. There might be some relation to the use of the <LAYER> tag in oneof the frames of the frameset? To reproduce the bug: goto http://www.derstandard.at and wait till the page is fully loaded. the center part of the scrollable frame will suddenly look blank. Scroll down within that frame until the first text in the center part becomes visible. Click on the first link to the right of little triangle that points to the right. Click the back button.
This should be filed as a new bug.
*** Bug 79740 has been marked as a duplicate of this bug. ***
Could it be that this has regressed somehow? I've seen a few "back button doesn't work" bugs recently and I've noticed it myself (on linux CVS builds during the last few days) - it seems again connected to framed sites, but I can't reproduce it. Back stops to work at all on a framed site, but once you visit a different site functionality is restored. New bugs that are similar: bug 99830, bug 100268, even older ones like bug 93445. Should we have a tracking bug for problem?
I tried this bug in a recent build. It has not regressed.
Mass removing self from CC list.
Now I feel sumb because I have to add back. Sorry for the spam.
I've just started using Mozilla 1.1 on Redhat 6.0 and I'm having problems with the back button while in the Zope environment (frame based); that is, sometimes I can go back to the previous page, sometimes I can't. I haven't discovered a pattern yet so I'm afraid I can't provide anything to reproduce. But I'm writing to ask if there are any patches which already exist for this problem. Anyone know of anything I might try? This functionality is really important to me at the moment. Thanks, N.
Component: History: Session → Document Navigation
QA Contact: claudius → docshell
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: