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)
Tracking
()
VERIFIED
FIXED
mozilla0.9.1
People
(Reporter: ezh, Assigned: radha)
References
()
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.
Comment 1•24 years ago
|
||
nav triage team: P4 for nsbeta1. nice to have. not terribly important.
Keywords: nsbeta1
Priority: P3 → P4
Comment 2•24 years ago
|
||
Adding mozilla0.9 keyword, since nsbeta1 doesn't apply anymore. Should nsbeta1 keyword be removed?
Keywords: mozilla0.9
Assignee | ||
Comment 4•24 years ago
|
||
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
Assignee | ||
Updated•24 years ago
|
Target Milestone: --- → mozilla0.9
Assignee | ||
Comment 5•24 years ago
|
||
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
Reporter | ||
Comment 6•24 years ago
|
||
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. :(
Reporter | ||
Comment 7•24 years ago
|
||
Now I must wait untill all pics are loaded and only then I can go further?
Comment 8•24 years ago
|
||
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
Reporter | ||
Comment 9•24 years ago
|
||
So, the bug is present but marked wontfix. Page is being rendered but is nit in SH... Or?
Assignee | ||
Comment 10•24 years ago
|
||
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.
Reporter | ||
Comment 11•24 years ago
|
||
What exactly mean "resolves"? PS I have a 950Ghz Duron, 320Mb RAM and a 3Mb cable connection...
Assignee | ||
Comment 12•24 years ago
|
||
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().
Reporter | ||
Comment 13•24 years ago
|
||
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.
Comment 14•24 years ago
|
||
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)
Comment 15•24 years ago
|
||
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.
Reporter | ||
Comment 16•24 years ago
|
||
So, I reopen it.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Comment 17•24 years ago
|
||
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.
Comment 18•24 years ago
|
||
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
Assignee | ||
Comment 21•24 years ago
|
||
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
Assignee | ||
Comment 22•24 years ago
|
||
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,
Comment 23•24 years ago
|
||
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
Assignee | ||
Comment 25•24 years ago
|
||
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.
Comment 26•24 years ago
|
||
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.
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.
Description
•