Open
Bug 869512
Opened 12 years ago
Updated 3 years ago
Transition the visibility property prevents the element being focus()'d
Categories
(Core :: Layout, defect)
Core
Layout
Tracking
()
NEW
People
(Reporter: timdream, Unassigned)
Details
Attachments
(1 file)
2.57 KB,
text/html
|
Details |
STR: See test cases. Attempt to create a fade-in/fade-out with CSS by transitioning opacity and visibility.
Expected: the dev is show and the input within the div gets the focus, as soon as the [Show and focus] button is pressed, on all three cases.
Actual: On Firefox Nightly, input fields on Case #1 and Case #3 failed to get the focus.
Note: Case #1 also fail on Chrome and Safari. Not sure if the behavior is correct here or not, but there is no mention of focus on CSS transition spec anywhere. If we could verify the behavior on the spec, I should probably file the same bug on Chromium and Webkit project too...
Note #2: For failed cases, if the user presses [hide] and press [show and focus] before the div is completely fade out, the focus() call will work.
Note #3: This should probably explain many of the Gaia System focus quirks :-/ though I discover this bug not because of Gaia...
Reporter | ||
Updated•12 years ago
|
Whiteboard: [TAIPEI_FND_TRACKING]
Reporter | ||
Comment 1•12 years ago
|
||
According to spec here:
http://www.w3.org/TR/css3-transitions/#animtype-visibility
<quote>
visibility: if one of the values is ‘visible’, interpolated as a discrete step where values of the timing function between 0 and 1 map to ‘visible’ and other values of the timing function (which occur only at the start/end of the transition or as a result of ‘cubic-bezier()’ functions with Y values outside of [0, 1]) map to the closer endpoint; if neither value is ‘visible’ then not interpolable.
</quote>
Interpretation of Kanru and I is that the case #1 is expected, as the rule regarding endpoint implies the element is still hidden at the function loop starting the transition. However, case #3 is indeed a bug on Gecko.
Kanru also said I should ask :dbaron about this. Is our interpretation of the spec correct? Is this a WONTFIX or a really bug?
Flags: needinfo?(dbaron)
So I suspect some of this is a function of what the value is right after starting the transition. A transition is supposed to transition gradually, so our implementation essentially starts at time 0, which means that until the next refresh driver tick, an element with a hidden -> visible transition remains hidden. (Maybe we shouldn't do this and should act as though we've already advanced one refresh driver tick.)
It's not clear to me why we refuse to focus something when visibility is hidden, though it seems vaguely sensible.
One workaround might be to use a -25ms transition-delay on the transition of the visibility property.
Flags: needinfo?(dbaron)
Reporter | ||
Updated•12 years ago
|
Whiteboard: [TAIPEI_FND_TRACKING]
Updated•3 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•