This is a highly weird problem and I hope I'm submitting it to the right entity. The above page uses an image for the background and the top table cell background. It scrolls just fine, but if you click the stop button (even when greyed) then scroll, the parts you scroll into will not contain the background! This results in a decidedly funky looking page. Give it a try with the URL above. I want to throw in a few comments as well: 1) I agree with the bug about table widths not being recognized if even one cell is left unspecified. This needs to be fixed pronto. 2) You cannot press "enter" to submit a form. That's also bad. 3) You cannot right-click paste into a form field. Bad. 4) This is pretty minor, but text wraps around images too tightly. There needs to be some automatic padding there. That's all for now!
confirming, win95 081509 (or something near that) Reporter: Please report separate bugs in separate reports. Thanks.
Absolutely and Positively strange! How can clicking on a grayed-out stob button cause the background image to disappear? And why doesn't clicking on the grayed-out Forward button do it? CC'ing hyatt in case he has some secret knowledge of the stop button ;)
The problem is that the disabled STOP button ends up being clickable! The click causes a call to nsPresContext::Stop(void) and that sets mStopped to TRUE and after that no images get loaded because StartImageLoad checks the mStopped. I think the STOP button should not be clickable when disabled: Dave, whaddaya think?
We had a bunch of similar cases in 4.x. Is there some awful thing (crash, data loss, severe leak scenario) that could happen because of it? If it is just background not loading, I'm inclined to just say 'don't do that'. BTW,I'm ignoring comments 1-4, they would need to be in separate bug reports to get any action, and are probably dups anyway.
All image loading is stopped when you press the disabled STOP button, so it is not restricted to the background image. Are you saying Peter that you would lean toward not fixing this? Isn't disabling buttons pretty simple?
*** Bug 48411 has been marked as a duplicate of this bug. ***
I don't think this has anything to do with the disabled Stop button (that seems to be a different bug). This bug happens when pressing the Stop button, disabled or not, or Stop on the context menu.
->xpapps, per hyatt
Nav triage team: changing component to Compositor. Here's another URL where you can see this problem: resource:///res/samples/test2.html
over to the compositor owners.
Don, this sounds like the bug where we don't display the background image if the image load has been stopped. probably a dup of 40388. Reassigning to dcone Marking nsbeta3-
The real problem with this bug is that the STOP button is setting mStopped to TRUE when we are not even actively loading. If the user is looking at a fully loaded page, and then accidentally presses the STOP button (which is disabled and should not even be clickable) then we set a flag stopping all subsequent image loading - scrolling or resizing causes their background image to disappear, and no images can be loaded via the DOM. This seems pretty serious. Blake Ross indicated that he thought there was a general problem with the STOP button, not just when disabled. I reply that if the user presses the STOP button while the page is loading then they really will want images to stop loading. If they press it when it is disabled then they probably expect nothing to happen. I cannot see how this is a Rendering problem - the problem is that the UI is telling the rest of the system to stop loading, when there is no loading going on, and that is wrong.
Marc: I agree that the user wants the images to stop loading if he presses Stop. However, he probably never wants the background of his scrollbar to get messed up (see bug 48411). He probably also doesn't want the background image to completely erase -- it should just remain at the point it was at when the user decided to stop loading it.
Why does this effect chrome? Hitting the stop button should not stop loading ANY chrome. Only HTML. Why does mStopped affect everyone?
I have a fix for this. I'll post a patch soon. Basically I added an argument called aStopChrome to Stop() in nsIPresContext. By default the argument is PR_TRUE. If you pass false it stops all images except those that point to chrome URLS. Currently all chrome URLs are local to your machine by definition so they can't be remote. I think this is a pretty safe solution for 6.0.
I have attached a fix for this bug in bug #52663 please review. -E
This also happens when you press ESC. What really made me notice is on sites where there are animated icons. I sometimes want to stop them, so I hit ESC. But then, all the backgrounds go away!
this bug happens all over at http://www.sourceforge.net also.
*** Bug 68330 has been marked as a duplicate of this bug. ***
*** Bug 50644 has been marked as a duplicate of this bug. ***
I agree that this should be given higher priority because it is totally lame. Don, can you address this or find somebody who can? evaughan had indicated that he might have a fix, but it only fixed the chrome images. To state my position clearly: Mozilla looks _silly_ if hitting 'escape' causes background images to go away. How professional ;)
*** Bug 69208 has been marked as a duplicate of this bug. ***
linux x86 2001-03-14-08 I no longer see this bug. Can anyone else confirm that it has been fixed?
Clicking the Stop button when it is greyed no longer seems to cause any problems. However, pressing the ESC key is still a problem, and it is the more serious problem in any case.
clicking a second time on a "visually disabled stop-button" was "fixed" - it does nothing now. That was deliberate. (bug 49773) But it only "cloaks" this bug - it isnt fixed at all.
This bug seems to be fixed now. Even the ESC keypress doesn't make the background image to disappear. Any comments from other people who have seen this bug?
Works for me with 2001102503 build on WINNT. Marking WFM.