Closed Bug 60780 Opened 24 years ago Closed 24 years ago

hitting STOP before any rendering is done causes current web page to become inactive

Categories

(Core :: Layout, defect, P3)

Product:
Core
Component:
Layout
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 76495
Milestone:
Future

People

(Reporter: brasten, Assigned: jst)

References

(
URL
)

Details

(Keywords: helpwanted)

From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0; DigExt) BuildID: 2000111704 I couldn't find this searching for bugs so sorry if it's been mass duplicated, but it only makes sense to me that if I am viewing, say.. www.netscape.com, and I type in, say, www.microsoft.com accidentally and immediately hit stop (upon realizing my error), it shouldn't deactivate www.netscape.com.. But it seems as though the currently rendered webpage become unresponsive while waiting to render the next.. if the next one never comes because it's terminated, the current one should still be considered the current page and work properly. Reproducible: Always Steps to Reproduce: 1. go to any url. 2. go to a second url, but hit stop before page loads up 3. try to interact with the page currently displayed (click on links, etc etc) Actual Results: can't do anything Expected Results: should be able to Also, in this case, hitting RELOAD causes the page you TRIED to go to to load up... in my opinion, (which could be wrong), if you're still on the first url, that one should reload.
I'm seeing this as well on 2000-11-18-20 on NT4.
update: it's not as easy to reproduce as I originally stated. it appears as though you have to STOP the process right AFTER the server's been contacted (and maybe sent a little data) but before enough data has been sent to render any page. This is resulting in an url and title from one site, but an unresponsive page from another site. Given the small amount of time in which STOP must be hit, perhaps this isn't terribly important... I just seem to do it quite often. :)
clicking the "back" button re-renders original page, tho. page you are still viewing actually doesn't exist for mozilla anymore and that's why it looks 'inactive', so the easiest resolution would be to clear window contents imeddiately (at least, signifocantly faster) when mozilla starts to transfer data and put some "navigation cancelled" or similar message.
over to Layout.
Assignee: asa → clayton
Status: UNCONFIRMED → NEW
Component: Browser-General → Layout
Ever confirmed: true
QA Contact: doronr → petersen
Please triage.
Assignee: clayton → jst
Seen this on Linux builds for ages now. OS->All. Why is this a "minor" bug? It renders the UI useless for pages when it occurs (until people figure out to hit the back button). Adding self to cc.
OS: Windows NT → All
I get this too all the time, and essentially how I would like it to work is: The page you are on remains active right until the point it is replaced by the new page. Only at the nano-second that the next page is visibly rendering do I want the first page to go inactive. So as long as I can see the page, I can use it fully. If I decide to alter the link I want to go to, I don't want to have to press 'stop' 'refresh' then the other link. Me: Win98 Build: 2000121608. Actually must note that it is alot harder for me to reproduce now as in months past, but that's down to Moz being so much faster and slicker and not giving me time to change my mind before the next page is in (that's good). I agree though this should be more than 'minor'
I have to agree this bug doesn't seem minor to me. Perhaps I'm indecisive, but I run across it all the time. Doesn't seen to be something that needs fixing TODAY, but it should be fixed before Moz1.0, as it could create quite a frustrating headache to average users.
This bug has been marked "future" because the original netscape engineer workingon this is over-burdened. If you feel this is an error, that you or another known resource will be working on this bug,or if it blocks your work in some way -- please attach your concern to the bug for reconsideration.
Hardware: PC → All
Target Milestone: --- → Future
*** Bug 68848 has been marked as a duplicate of this bug. ***
Clearing URL from "any". Nominating for mozilla0.9. Easy workaround although not immediately obvious but major loss of function (can't click links, scroll page). Upping to Normal severity. People ARE going to notice this, and many may dismiss the product in favour of IE/Opera if they do not realise that reloading the current page re-activates the page's links and scrolling view. Some on slow connections may suffer quite a bit with this.
Severity: minor → normal
Keywords: mozilla0.9
This is a major bug, because - the page is completely disfunctional - it happens frequently It happens frequently that I see an interesting link during the load (when the old page is still displayed) and I change my mind and want to see that link, too. So, I stop to open follow both links, but I can't anymore. Please reconsider for mozilla 0.9.
Severity: normal → major
I would love to look into this, but I simply don't have any time for this in the mozilla0.9, or mozilla0.9.1 timeframe, if this should be fixed sooner this bug needs a new owner, unfortunately I don't know who that would be. Maybe someone could ask around on the newsgroups to see if someone could sign up for this?
*adding self to CC* might this be more of a History:session bug than a layout bug? Not that Radha isnt overbusy too :)
jst, but the bug is in your area, isn't it?
Keywords: helpwanted
The bug seems more like a docshell bug to me. It was originally filed as Layout and then assigned to jst for triage, not because he was the right person.
Ben, possibly, but as David says it's also related to docshell, I actually discussed this with rpotts a week ago or so and he thought that it wouldn't be too hard to leave the current document active for a while longer until we know we actually have something to show in the new document (which could be a while if the new document uses stylesheets that are loaded "synchronously" while the parser is blocked. This doesn't change my statemet tho, I still don't have any time to spend on this now.
*** Bug 68897 has been marked as a duplicate of this bug. ***
Isn't this a dupe of bug 5569 ?
no, close, but not quite.
Related to, or perhaps even a duplicate of, bug 76495.
Ack! I detect some circular dupe-logic here! One of these has to be the "real" one. :)
*** This bug has been marked as a duplicate of 76495 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.