Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[CLOSED] Fix #10142. LiveDev2: Firefox highlight does not have fade-away effect. #9002

Open
core-ai-bot opened this issue Aug 30, 2021 · 3 comments

Comments

@core-ai-bot
Copy link
Member

Issue by busykai
Thursday Dec 11, 2014 at 18:34 GMT
Originally opened as adobe/brackets#10151


Fixes #10142.

Wait a little longer for the highlight element to take it's initial state. If
the element is not yet in its initial state, the transition does not happen. It
seems like on Firefox/Gecko it takes longer than on Chrome/Webkit.

This is a quote from MDN article on subject:

Care should also be taken when using a transition immediately after adding the element to the DOM using .appendChild() or removing its display: none; property. This is seen as if the initial state had never occurred and the element was always in its final state. The easy way to overcome this limitation is to apply a window.setTimeout() of a handful of milliseconds before changing the CSS property you intend to transition to.

CC:@dangoor,@redmunds


busykai included the following code: https://github.com/adobe/brackets/pull/10151/commits

@core-ai-bot
Copy link
Member Author

Comment by cheesypoof
Friday Dec 12, 2014 at 16:03 GMT


I haven't looked at this issue first-hand, but the description reminded me of an item in the Firefox 34 developer release notes.

Fixed starting of CSS transitions that start together with changes to display, position, overflow, and similar properties (bug 887541)

Do you think that fix could be relevant to this issue?

@core-ai-bot
Copy link
Member Author

Comment by busykai
Friday Dec 12, 2014 at 17:40 GMT


@cheesypoof, thanks for the reference. I'll look into it to see if our code could be reorganized. From the looks of it, it sounds like that FF does not do appendChild synchronously hence requiring a tangible wait period (well, 20ms is not perceivable, but still longer than just yielding). The issue was still reproducible with the Aurora latest versions (~FF 36).

@core-ai-bot
Copy link
Member Author

Comment by redmunds
Wednesday Jan 14, 2015 at 22:40 GMT


Much better! Thanks. Merging.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant