Cannot stop animation with escape key

VERIFIED FIXED in Firefox1.0beta

Status

()

P4
normal
VERIFIED FIXED
16 years ago
13 years ago

People

(Reporter: jmd, Assigned: bugzilla)

Tracking

({access, fixed-aviary1.0})

unspecified
Firefox1.0beta
access, fixed-aviary1.0
Points:
---
Bug Flags:
blocking0.9 -
blocking-aviary1.0 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: parity-ie)

Attachments

(2 attachments)

(Reporter)

Description

16 years ago
Fix for suite needs to be applied to Firebird as well.

Bug 70030.

Comment 1

16 years ago
Don't we get this for free in Firebird?  The fix for bug 70030 was in
nsDocumentViewer.cpp, not front-end code.
(Reporter)

Comment 2

16 years ago
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.

Updated

16 years ago
OS: Linux → All
Hardware: PC → All

Updated

16 years ago
QA Contact: asa

Comment 3

16 years ago
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.

Comment 4

16 years ago
Created attachment 133149 [details] [diff] [review]
alternative patch: always enable the stop button, menu item, and keyboard shortcut

Comment 5

16 years ago
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.

Comment 6

16 years ago
Read: bug 21623 comment 12.

Updated

16 years ago
Attachment #133149 - Flags: review?(blake)

Comment 7

16 years ago
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

Comment 8

15 years ago
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).
(Reporter)

Comment 9

15 years ago
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?

Updated

15 years ago
Attachment #133149 - Flags: review?(blake)

Updated

15 years ago
Attachment #133147 - Flags: review?(p_ch)

Comment 10

15 years ago
I agree with rbs's comment #5. But I won't have time to work on it.
rbs: is someone working on it?

Comment 11

15 years ago
> 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...

Comment 13

15 years ago
*** Bug 225348 has been marked as a duplicate of this bug. ***

Updated

15 years ago
Keywords: access

Comment 14

15 years ago
*** Bug 240689 has been marked as a duplicate of this bug. ***

Updated

15 years ago
Whiteboard: parity-ie

Updated

15 years ago
Flags: blocking0.9?
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. 
Flags: blocking1.0+
Flags: blocking0.9?
Flags: blocking0.9-
(Assignee)

Comment 16

15 years ago
Fixed.
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED

Comment 17

15 years ago
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 18

15 years ago
Comment on attachment 133147 [details] [diff] [review]
patch to always enable Esc (but not stop button)

9 months from patch to checkin. Oh well.
Attachment #133147 - Flags: review?(p_ch)

Updated

15 years ago
Keywords: fixed-aviary1.0

Comment 19

15 years ago
*** Bug 256062 has been marked as a duplicate of this bug. ***

Comment 20

15 years ago
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.