Closed Bug 55860 Opened 25 years ago Closed 25 years ago

Can't interact with page while loading another page in the same browser window

Categories

(Core :: DOM: UI Events & Focus Handling, defect, P3)

Product:
Core
Component:
DOM: UI Events & Focus Handling
Platform:
PowerPC
All
Type:
defect

Tracking

()

Status:
VERIFIED WORKSFORME
Milestone:
mozilla0.9.1

People

(Reporter: devsin, Assigned: joki)

References

Details

(Keywords: verifyme)

Mozilla M18 2000100608 - (Guessing component, feel free to revise summary with a better description 'cause I couldn't think of one) When loading pages, there is a delay from when the server is contacted to when the page is actually displayed. During this delay, it is impossible to do anything inside the browser window. You can't scroll the current page, click on any links, etc. This is probably most notable with slower connections where the delay can last 10 seconds or more. This prevents a user from clicking a different link (if they clicked the wrong one or changed their mind, etc.) without loading the link they first clicked on. It also prevents somebody from scrolling the current document (thereby being able to read the page) while another one is loading (I like to click a link and then keep the scroll bar depressed so I can read the page and then have the other one load immediately when I release the scroll bar). My thought is that as long as a page is visible, the user should be able to interact with it. I can see two obvious solutions to this: 1) Decrease the delay when the server is first contacted and when the page appears on the screen. This could be a performance issue, but I believe not (I recall that the delay between server contact and receiving/displaying data was added for various reasons). 2) Create an intermediate page that is displayed when the server is contacted. This could be a simple blank page (or perhaps a "Loading..." page) that would let the user know that the server has been contacted and data is being sent. This would eliminate the virtual "freeze" that happens during the delay. Again, as long as a page is visible, a user should be able to interact with it. The delay can be mistaken as a crash as you can't perform any action inside the browser window. At the very least, it is annoying to have a 5-10+ second delay where you have to just sit and twiddle your thumbs. 10 seconds doesn't seem like a long time, but it really begins to add up if you use the browser for any period of time. And I imagine the delay depends on the speed of your connection (28.8K users beware!)
Also, if you stop loading a page during this delay, you cannot interact with the contents of the page at all - you have to manually type in a new URL, choose a bookmark, etc.
would this be a networking or event handling issue? or, something else? guessing the former...but do change if necessary. thx!
Assignee: don → gagan
Component: XP Apps → Networking
QA Contact: sairuh → tever
gordon: are you familar with this problem?
OS: All
Keywords: verifyme
This bug happens when new page has already begun to load. Browser contents is not replaced with new content(blank page if it only has downloaded something like <html>). So content of the last page is still visible, but in fact it is new page. Probably this bug depends on 5569 http://bugzilla.mozilla.org/show_bug.cgi?id=5569
This bug happens when new page has already begun to load. Browser contents is not replaced with new content(blank page if it only has downloaded something like <html>). So content of the last page is still visible, but in fact it is new page. Probably this bug depends on 5569 http://bugzilla.mozilla.org/show_bug.cgi?id=5569
Depends on: 5569
Assignee: gagan → joki
Component: Networking → Event Handling
QA Contact: tever → gerardok
my understanding of this bug says this is more to do with general events processing than networking. changing component as such.
The described failure is a regression in NS 6.x. that impacts the real-usability of the product for navigating, and browsing the web, e.g. you can't click on another link if you've changed your mind on what to download, or even scroll down to continue reading at the bottom of the page. I think it'd be annoying for users being forced to wait for the new page to complete download, whitout any possiblity for interacting with the UI. Bumping severity to major as it causes temporarly a major loss of a function, namely UI responsiveness to user commands. Nominating for NS 6.5 beta 1 because, if fixed, it would be an excellent value added to the overall product usability. Adding selmer to Cc list.
Severity: normal → major
Keywords: nsbeta1
Keywords: nsbeta1 → nsbeta1+
Target Milestone: --- → mozilla0.9.1
With the fix of 5569 I'm going to go with worksforme on this. I believe the problem this bug was opened for was based on the dead content in the window which the user would have believed to be live and wouldn't understand why it didn't work. With the fix for 5569 we wipe out the dead content. The white screen still stares at you until we have content to add but the UI is responsive and I don't have the impression of a dead browser. I ran the browser through a 14.4 proxy and found that while the browser was doing name lookup the old content still existed and was valid and the UI worked. After connection was made we now jump to a blank white screen, the UI continues to work. While content is being loaded you can interact with the partially loaded content and the UI. Now this last point I admit isn't necessarily optimal. When loading through the proxy my machines had plenty of spare cycles and everything was pretty fast. When loading through my cable modem the machine was struggling to render the quickly streamed data while at the same time respond to my UI actions and link clicking, but it did behave correctly if sluggishly. I think thats just machine speed and a general issue of performance.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
The main issue of this bug was the ability of a user to stop loading a new page before it was drawn to the window. This created the problem where the old page was still visible, but the user couldn't interact with it. With the fix to bug 5569, the old contents of a page are erased (about:blank is drawn) once the new page begins to load, so it is no longer possible to leave the user with an inactive window. Marking verified.
Status: RESOLVED → VERIFIED
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.