Closed Bug 58906 Opened 24 years ago Closed 24 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 → 24 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.