Closed
Bug 49222
Opened 24 years ago
Closed 23 years ago
Clicking stop button causes background image to disappear when scrolling
Categories
(Core Graveyard :: GFX, defect, P3)
Tracking
(Not tracked)
RESOLVED
WORKSFORME
Future
People
(Reporter: nbradgarrett, Assigned: dcone)
References
()
Details
(Keywords: testcase, Whiteboard: [nsbeta3-])
Attachments
(1 file)
416 bytes,
text/html
|
Details |
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!
Comment 1•24 years ago
|
||
confirming, win95 081509 (or something near that) Reporter: Please report separate bugs in separate reports. Thanks.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 2•24 years ago
|
||
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 ;)
Assignee: clayton → attinasi
Comment 3•24 years ago
|
||
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?
Assignee: attinasi → hyatt
Keywords: nsbeta3
Comment 4•24 years ago
|
||
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.
Whiteboard: [need info]
Comment 5•24 years ago
|
||
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?
Comment 7•24 years ago
|
||
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.
Comment 8•24 years ago
|
||
->xpapps, per hyatt
Assignee: hyatt → don
Component: Layout → XP Apps
QA Contact: petersen → sairuh
Comment 9•24 years ago
|
||
Nav triage team: changing component to Compositor. Here's another URL where you can see this problem: resource:///res/samples/test2.html
Component: XP Apps → Compositor
Comment 10•24 years ago
|
||
over to the compositor owners.
Assignee: don → kmcclusk
QA Contact: sairuh → petersen
Comment 11•24 years ago
|
||
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-
Assignee: kmcclusk → dcone
Whiteboard: [need info] → [nsbeta3-]
Assignee | ||
Updated•24 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → Future
Comment 12•24 years ago
|
||
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.
Comment 13•24 years ago
|
||
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.
Comment 14•24 years ago
|
||
Why does this effect chrome? Hitting the stop button should not stop loading ANY chrome. Only HTML. Why does mStopped affect everyone?
Comment 15•24 years ago
|
||
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.
Comment 16•24 years ago
|
||
I have attached a fix for this bug in bug #52663 please review. -E
Comment 17•24 years ago
|
||
Comment 18•24 years ago
|
||
I noticed that this also happens if I open up the bugzilla javascript bookmark for locating bugs (found on the bugzilla homepage). Also the background is removed even if it was fully loaded.
Comment 19•24 years ago
|
||
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!
Comment 20•24 years ago
|
||
this bug happens all over at http://www.sourceforge.net also.
Updated•24 years ago
|
Keywords: mozilla1.0
Comment 21•24 years ago
|
||
*** Bug 68330 has been marked as a duplicate of this bug. ***
Comment 22•24 years ago
|
||
*** Bug 50644 has been marked as a duplicate of this bug. ***
Comment 23•24 years ago
|
||
Personally, I would rank this bug higher than minor and future. If someone uses ESC to stop the annoying animated ads on a site and the background image disappears and onMouseOver JavaScript loaded images stop loading (menu bars, etc.: see the example in bug 68330), I think they will be very surprised and will be tempted to think Mozilla is very broken.
Comment 24•24 years ago
|
||
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 ;)
Comment 25•24 years ago
|
||
*** Bug 69208 has been marked as a duplicate of this bug. ***
Comment 26•23 years ago
|
||
linux x86 2001-03-14-08 I no longer see this bug. Can anyone else confirm that it has been fixed?
Comment 27•23 years ago
|
||
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.
Comment 28•23 years ago
|
||
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.
Comment 29•23 years ago
|
||
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?
Comment 30•23 years ago
|
||
Works for me with 2001102503 build on WINNT. Marking WFM.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
Updated•16 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•