Fix for suite needs to be applied to Firebird as well. Bug 70030.
Don't we get this for free in Firebird? The fix for bug 70030 was in nsDocumentViewer.cpp, not front-end code.
Perhaps Firebird's frontend is hooked up to different back-end code. All I know is pressing ESC, clicking stop, or selecting view->stop does nothing in any recent Firebird build. Adding assignee of Suite bug to CC, in case he can perform a quick fix here.
Created attachment 133147 [details] [diff] [review] patch to always enable Esc (but not stop button) After applying this patch, you must |touch browser.xul| (bug 221940) before you rebuild. I don't know what implications this has for actually checking it in. This patch makes Firebird behave the same was as Seamonkey: pressing Esc stops animations even though the stop button and menu item are disabled. An alternative approach would be to leave all the stop things enabled all the time (button, menu item, etc), like IE does.
Created attachment 133149 [details] [diff] [review] alternative patch: always enable the stop button, menu item, and keyboard shortcut
Comment on attachment 133149 [details] [diff] [review] alternative patch: always enable the stop button, menu item, and keyboard shortcut Mozilla's intended behavior (when implemented as per bug 21623 comment 21623) is going to be better.
Read: bug 21623 comment 12.
Is this the same as changing the image.animation_mode to never and it not working anyway (meaning it continues to animate) or do I need to file another bug? I am using the latest release Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 Firebird/0.7
Last week on IRC, noririty pointed out that some people (including him) use the stop button as a loading indicator. So maybe it would be better to just enable Esc (first patch).
Just ESC sounds good to me. GIF animation stopping isn't such a critical feature that we should change the stop button behavior. Perhaps remove the review flag on the second attachment and seek a review for the first?
I agree with rbs's comment #5. But I won't have time to work on it. rbs: is someone working on it?
> rbs: is someone working on it? [i.e., bug 21623 comment 12] Not to my knowledge. If someone is insterested, they may perhaps chat with bz who made images load from the content; bz might know a slick way to notify XUL that an animated image was encountered, allowing to sync the unfinished patch of bug 21623 In the meantime, the simple ESC patch here seems fine to me. The alternative patch looked off the mark.
It's trivial to detect multi-frame images. The question is whether a multi-frame image that doesn't loop should count for "animation" purposes. I don't know that we can distinguish those from ones that do loop via the public libpr0n apis...
*** Bug 225348 has been marked as a duplicate of this bug. ***
*** Bug 240689 has been marked as a duplicate of this bug. ***
The always-enabled stop button is annoying (especially since it's a subtlety that 99.9% of users won't understand), but the escape option is fine.
15 years ago
Priority: -- → P4
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
Verifying with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040715 Firefox/0.9.1+ (Steffen). Checkin was 2004-07-12 20:24. Removing "stop button" from summary because that hasn't changed. Setting target to state when it was fixed.
Status: RESOLVED → VERIFIED
Summary: Cannot stop animation with stop button or escape key → Cannot stop animation with escape key
Target Milestone: --- → Firefox1.0beta
Comment on attachment 133147 [details] [diff] [review] patch to always enable Esc (but not stop button) 9 months from patch to checkin. Oh well.
*** Bug 256062 has been marked as a duplicate of this bug. ***
See also bug 256062, "Stop button should stop animations".
You need to log in before you can comment on or make changes to this bug.