Open
Bug 933690
Opened 11 years ago
Updated 2 years ago
stroke dashoffset is not working
Categories
(Core :: CSS Parsing and Computation, defect, P4)
Tracking
()
UNCONFIRMED
People
(Reporter: niloy.mondal84, Unassigned)
Details
(Keywords: testcase)
Attachments
(1 file)
407 bytes,
text/html
|
Details |
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0 (Beta/Release)
Build ID: 20130910160258
Steps to reproduce:
Visit this fiddle: http://jsbin.com/etICIq/2/edit
Hover over the black box in output area.
Actual results:
Nothing happened.
Expected results:
The visible width of the black box should animate to 0.
Works in Chrome.
Reporter | ||
Comment 1•11 years ago
|
||
Also, if you visit this page: http://tympanus.net/Development/AnimatedCheckboxes/
The svg animation works beautifully in Chrome but horribly broken in Firefox.
Comment 2•11 years ago
|
||
Seems to be an issue with the CSS animation and pixel values. If you remove the px units then it works OK doesn't it?
Comment 2 is a separate issue isn't it? In which case it needs to be a separate bug. Having said that rhw animation works fine for me.
Updated•11 years ago
|
Component: Untriaged → SVG
Product: Firefox → Core
Reporter | ||
Comment 3•11 years ago
|
||
Am using Windows 7. If I remove the 'px', there seems to be some kind of horrible flickering going on. I dont think Comment 2 is a separate issue, the fiddle I created is just a reduced test case of the problem.
Comment 4•11 years ago
|
||
Precisely what is wrong with that page then? It all looks fine to me so perhaps I just don't know what to look at.
Comment 5•11 years ago
|
||
As far as I can see this bug is a duplicate of bug 556441. The first instance of dash-offset doesn't have units and the second instance (in the hover) does. If you make them both have units or neither have units then everything works as far as I can see. Is there anything here that's not covered in that bug?
Reporter | ||
Comment 6•11 years ago
|
||
The smooth animation to zero width is not happening at all. Instead, the black bar simply flickers a lot. I am guessing you are not able to replicate the issue, maybe someone else can.
Comment 7•11 years ago
|
||
I am with the original testcase, but if I modify it so that both cases of stroke-dashoffset have units in both cases then it's fixed (same if neither have units).
Reporter | ||
Comment 8•11 years ago
|
||
I am able to replicate the issue even with same units(px or none).
Comment 9•11 years ago
|
||
That's really strange if I change to this:
#a {
stroke-dasharray: 200px 200px;
stroke-dashoffset: 0px;
transition: stroke-dashoffset .5s;
}
#a:hover {
stroke-dashoffset: 200px;
}
Then I get a smooth animation provided I don't move the mouse about. Can you try Firefox 25, that's what I'm using.
Comment 10•11 years ago
|
||
Listen dude, this issue has been around for 2 years now and it's absolutely ridiculous that it has yet to be fixed. It's makes it practically impossible to implement any cool line-drawing effects until it's fixed. This issue has NOTHING TO DO WITH ANIMATIONS. It's simply a problem with hardware acceleration on Windows operating systems (maybe if you took two seconds to Google the problem you'd figure that out yourself). The stroke-dashoffset value for some reason is a factor of the stroke-width, when it shouldn't be. In order to achieve the proper stroke-dashoffset (when experiencing the issue), you have to divide it by the current stroke-width to fix the issue, but then the animations wouldn't work on non-Windows operating systems or when hardware acceleration is disabled.
But go ahead, keep neglecting to fix this issue. And you people wonder why Chrome is continuing to take a larger and larger market share while less and less people continue to use Firefox. It's silly little bugs like this and clunky performance that have forced me to use Chrome for the past 4+ years.
![]() |
||
Comment 11•11 years ago
|
||
(In reply to redtoline from comment #10)
> This issue has NOTHING TO DO WITH ANIMATIONS.
This bug _IS_ to do with animation - the original reporter said in comment 0 "The visible width of the black box should animate...".
I've no idea what bug you're experiencing, but please file a new bug report, and attach a testcase that demonstrates the issue:
https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=SVG
Comment 12•11 years ago
|
||
(In reply to Robert Longson from comment #9)
> That's really strange if I change to this:
>
> #a {
> stroke-dasharray: 200px 200px;
> stroke-dashoffset: 0px;
> transition: stroke-dashoffset .5s;
> }
>
> #a:hover {
> stroke-dashoffset: 200px;
> }
Agreed, that feels like a style system bug to me.
David, do you see any reason why the transition works with "0px" but not with "0"?
Comment 13•11 years ago
|
||
We know that, it's bug bug 556441 (comment 5). The reporter claims that when he fixed that he still had issues which I don't see myself.
Flags: needinfo?(dbaron)
Reporter | ||
Comment 14•11 years ago
|
||
Yes, even after fixing the dimensions, I am still facing the problem.
Robert, are you using Windows?
Comment 15•11 years ago
|
||
Yes: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20100101 Firefox/25.0
so pretty much the same as you.
Comment hidden (abuse-reviewed) |
Comment 17•11 years ago
|
||
redtoline Please read https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
If you don't take your comments to another bug and keep a civil tone you'll get banned.
If you can be civil in another bug and provide a testcase we'll look into it.
Comment 18•11 years ago
|
||
(In reply to Robert Longson from comment #13)
> We know that, it's bug bug 556441 (comment 5). The reporter claims that when
> he fixed that he still had issues which I don't see myself.
Oh, sorry I missed that. So on Linux and OSX I see an animation to zero
and then back to 200px (if I use the mouse to hover). On Windows 7
I see quite a bit of flickering before it settles. Using *keyboard
commands* to switch back and forth between tabs, leaving the mouse
over the area, I see one transition per switch (on OSX and Linux).
On Windows I get no transition at all when switching between tabs
with CTRL+1 / CTRL+2 (you have to save the test to a local file
first though because jsbin.com hijacks those kbd commands).
So it seems this is an event handling and/or style system bug and
not something specific to SVG. I think we have several bugs on
similar hover transition problems with other types of content.
Component: SVG → CSS Parsing and Computation
Comment hidden (abuse-reviewed) |
Comment 20•11 years ago
|
||
(In reply to redtoline from comment #19)
> And I'll explain it in more detail if that didn't make enough sense to you,
> since I realize I'm talking to a bunch of incompetents in QA.
Thank you for helping us mere mortals understand the problem better,
but can you please try to be civil? There really is no need to
insult people like that.
Comment 21•11 years ago
|
||
I can confirm that I get the same behavior on Windows as on Linux/OSX
when I disable HW acceleration on Windows. Still doesn't seem like
an SVG specific issue to me.
Comment hidden (abuse-reviewed) |
Comment 23•11 years ago
|
||
Comment hidden (abuse-reviewed) |
![]() |
||
Comment 36•11 years ago
|
||
Like in Bug 661812 Comment 17, I see http://tympanus.net/Development/AnimatedCheckboxes/ and the attached Testcase improved/fixed on Firefox 28+ (Win 7 + HWA on).
Progression Range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=545887140a1b&tochange=9cd9aae255b5
=> fixed by Bug 935994 (restriced bug), too?
=> Dupe of Bug 661812?
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•