Open Bug 933690 Opened 11 years ago Updated 2 years ago

stroke dashoffset is not working

Categories

(Core :: CSS Parsing and Computation, defect, P4)

24 Branch
x86_64
Windows 7
defect

Tracking

()

UNCONFIRMED

People

(Reporter: niloy.mondal84, Unassigned)

Details

(Keywords: testcase)

Attachments

(1 file)

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.
Also, if you visit this page: http://tympanus.net/Development/AnimatedCheckboxes/ The svg animation works beautifully in Chrome but horribly broken in Firefox.
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.
Component: Untriaged → SVG
Product: Firefox → Core
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.
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.
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?
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.
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).
I am able to replicate the issue even with same units(px or none).
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.
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.
(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
(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"?
Flags: needinfo?(dbaron)
Keywords: testcase
Priority: -- → P4
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)
Yes, even after fixing the dimensions, I am still facing the problem. Robert, are you using Windows?
Yes: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20100101 Firefox/25.0 so pretty much the same as you.
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.
(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
(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.
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.
Restrict Comments: true
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?
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: