Closed Bug 58906 Opened 24 years ago Closed 23 years ago

Frame is not in history when it wasn't load completely, so no back to it

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: ezh, Assigned: radha)

References

(
URL
)

Details

(Whiteboard: nsbeta1+) 

From bug 46828:

1. Load http://www.grandprixgames.com/
2. Press English
3. Press Reviews
4. Press Screenshot and immediately press Game info (do not wait until 
screenshots were loaded!!!)
5. back moves you to Reviews
6. Go again pp. 4 and 5
7. and again 4-5
8. The result is: you are taken to Reviews
9. Now go again to screenshots, wait until they all are loaded
10. Go to Game Info
11. Pressing back moves you to screenshot just as it should be...

So we have a test when doesn't completely loaded (not cached?) frame does not go 
back.

I take a risk and make this bug again [RTM need info] - there's tons of framed 
pages and they are unusable. This bug, bug with disabled back button and I feel 
the bug about cached frame is a new one...

Also reprodusible on www.avp.ee.
nav triage team: P4 for nsbeta1. nice to have. not terribly important.
Keywords: nsbeta1
Priority: P3 → P4
Adding mozilla0.9 keyword, since nsbeta1 doesn't apply anymore. Should nsbeta1
keyword be removed?
Keywords: mozilla0.9
Blocks: 59387
nav triage team:

Marking nsbeta1+
Whiteboard: nsbeta1+
Frames or any page gets in to SH once the url is resolved. So, if the user
clicks back/forward quickly or goes somewhere else before necko and docloader
had a chance to resolve the url, we will not be adding those urls to SH. That is
how the design is going to stay. I will look in to this case, if any redirection
or document.write() is contributing to the problem.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9
I do not see any redirection or document.write() related problems in this site. 
As I stated earlier, by design we will not add urls to SH, if their load is 
interrupted too soon ie., before we even create content-viewer, (once the url is 
resolved by necko). Changing this policy has several other repercursions. 
However, back/forward works just fine if the subframes had a chance to even 
partially load. 

Marking Won't fix.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → WONTFIX
So you suggest to use other brower with framed sites?

Just tried out Opera - works how it should, but not mozilla... And now it is
wontfix. :(
Now I must wait untill all pics are loaded and only then I can go further?
I suspect radha may not be talking about the problem you are seeing. As I 
understand it, he says that "if the URL is not resolved, it's not added to the 
history." Your problem happens when the URL is resolved, the page is requested, 
data is returned and starts being rendered. By this time, the URL should be in 
the history. If it isn't, that's a problem.

Gerv
So, the bug is present but marked wontfix. Page is being rendered but is nit in
SH... Or?
Please note that there is also a timing issue. THe url may not resolve in a slow 
machine with a modem, but resolve and begin to render in a faster machine. I'm 
*not* saying  that Eugene or somebody has a slow machine and there by happens in 
their machine and not  mine. If a page starts rendering and then you click 
elsewhere before it finishes, it does get added to SH and  we do try to go back 
to it when the user presses back or forward. If its not, then we don't.  You 
don't have to wait for the whole page to load to make sure that it is in SH. 
Just enough time so that it resolves is sufficient. 
What exactly mean "resolves"?

PS I have a 950Ghz Duron, 320Mb RAM and a 3Mb cable connection...
By "URL resolution", I mean, necko made a successful connection with the server, 
(ie., the url is not a invalid or a unreachable url), the docloader sent out a 
OnStartRequest notification to nsIWebProgressListener, docloader found a content 
listener for the content type and initiates the creation of content viewer.  
DocShell adds a url to SH only after these things have happened. If a url 
loading is interrupted before the creation of content viewer, it will not 
be added to SH. If a url loading is interrupted after the creation of content 
viewer, it will not be removed from SH, unless the subsequent load requests to 
replace the existing entry, eg., a JS location.replace(). 
But I see the content, only pictures are not loaded. And this site is not added
to SH...

Try to repro at nr. 4, but press Game when some content already appears.
to be honest, i can't reproduce this bug - win32 2001021404 mtrunk installer. 
and i'm running a p150 64meg ram with about 90megs of space (before mozilla
cache) and a 56k modem.

but the issue of a page's resolution with relation to both its entry into the
history and the actual appearance of content on the screen is an important one.
 i have yet to see a distinct problem with it myself, or at least not one that
isn't seen in nav 4.xx as well.  B)

I was able to reproduce it with 2001021508 (Mozilla0.8)
When I click another link before all images are loaded, the page being loaded is 
not recorded in history.

And this one might make into the mostfreq soon as I was about to file this one 
independently yesterday about another site.
So, I reopen it.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
I am having a very similar problem in Mozilla 0.9 when working with a personal
web page - <URL:http://www.charm.net/~bradj/> - links clicked in the bottom
frame to load in the middle one will load the content OK, but you aren't able to
hit the back button to navigate to the last page that occupied that center
frame.  Very annoying.  Right-clicking in the frame I'm looking to navigate
backward in and hitting "Back" has no effect.
I'm seeing a similar bug in 0.8.1 build 2001-0323-19 Win32.

Navigating through an intranet site here the Back button and the Back option on
the pop-up menu never even become active, after going through several pages
within one frame.

This must have (re?)broken somewhat recently, it works ok in Netscape 6.01
*** Bug 73602 has been marked as a duplicate of this bug. ***
*** Bug 45864 has been marked as a duplicate of this bug. ***
Couldn't make it to 0.9. moving to 0.9.1
Status: REOPENED → ASSIGNED
Priority: P4 → P1
Target Milestone: mozilla0.9 → mozilla0.9.1
I tried out the original problem reported here. I'm having trouble reproducing 
it. I cleared out my cache and set 0 memory  and disk cache so that images will 
be obtained from net for subsequent loads. I click on "press reviews", then, 
"screenshots". while  screen shots are loading, I clicked on "Technical 
specifications".  Clicking back after tech specs are loaded, takes me to screen 
shots.  The problem was in the OnStopRequest notifications sent by necko. I'm 
guessing that some of the recent checkins by Darin fixed the notification 
problem. Can someone try this and update me? Thanks,
PDT decided to mark this fixed so we can get some testing on this and try to
verify it.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → FIXED
Can someone check to see if this is truly fixed in the latest builds?
claudius sent me this message in an email about this bug:

Radha, I'm using a 2001052208 Mozilla build on my redhat Linux system. It is a
_very_ slow machine ~120Mhz pentium. I can reproduce the bug but only with much
effort by immediately clicking on the two succesive links. This sounds like what
you were explaining in the bug about appending SH after URL resolution, but I'll
leave that up to you.

I don't know whether to call this bug fixed or not -- i can only repro the error on a machine slow
enough to allow my reflexes to beat out the processor's. And even then it seems contrived that
I have to try so hard to do it. I can't imagine this would happen in any normal situation and don't
know if it can be prevented in the one situation I can reproduce it in.

If anyone else can repro this on a faster machine(i doubt it) I'd love to hear about it.

marking VERIFIED
Status: RESOLVED → VERIFIED
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.