fixes for Firefox #223
fixes for Firefox #223
Conversation
- SVGs don't have height in Firefox, so we have to fallback to the parentElement's height in order to calculate scale correctly. When the `drag` handler was used on a `.handle` element that was an SVG, the value of `scale` was always zero. Now it is the correct value (usually 1). - Use the `transitionend` event to wait for events to finish. In chrome, these animations were scheduled in such a way that the dom elements were technically in the right order but visually inaccurate if we slowed the transitions down. In Firefox, the smoke tests failed due to the elements being out of order. In addition to using the `transitionend` event (which is supported by all browsers we support(https://developer.mozilla.org/en-US/docs/Web/Events/transitionend#Browser_compatibility), when `DEBUG` mode is active (e.g. development or test builds, not production builds`, we emit a custom event on the document and use a custom waiter to prevent Ember from advancing the test suite too fast before the transitions are done (the transforms need to finish so that the elements are in the correct order in the dom). - Add Firefox to our .travis.yml and testem.js files so that we test against Firefox in CI.
|
Released in 1.12.4 |
|
Breaks all drag & drop usages on my applications .. (tested on Safari, Chrome and Firefox) ... |
|
@BnitoBzh very sorry to hear that. Are you able to give us any code snippets that will help us figure out what happened here? Are you OK to downgrade for the time being? |
|
@jgwhite I have no code snippet, i am using ember-sortable in its basic way, (readme example). |
|
@BnitoBzh no problem. We’ll look into it and make a note on this thread when a fix lands. |
|
@BnitoBzh Can you open this as a new issue? Thanks |
|
Am having the same bug where |
parentElement's height in order to calculate scale correctly. When the
draghandler was used on a.handleelement that was an SVG, thevalue of
scalewas always zero. Now it is the correct value (usually1).
transitionendevent to wait for events to finish. This prevents race conditions versus trying to extract the time from the styles. In chrome,these animations were scheduled in such a way that the dom elements were
technically in the right order but visually inaccurate if we slowed the
transitions down. In Firefox, the smoke tests failed due to the elements
being out of order. In addition to using the
transitionendevent(which is supported by all browsers we
support(https://developer.mozilla.org/en-US/docs/Web/Events/transitionend#Browser_compatibility),
when
DEBUGmode is active (e.g. development or test builds, notproduction builds`, we emit a custom event on the document and use a
custom waiter to prevent Ember from advancing the test suite too fast
before the transitions are done (the transforms need to finish so that
the elements are in the correct order in the dom).
against Firefox in CI.