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.

  

  



    
    

    
  
OK, filed bug http://bugzilla.mozilla.org/show_bug.cgi?id=83684

  

  



    
    

    
  
*** 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: