Jump to content
Search Community

Draggable: only Firefox refuses to click?

Anitainment test
Moderator Tag

Warning: Please note

This thread was started before GSAP 3 was released. Some information, especially the syntax, may be out of date for GSAP 3. Please see the GSAP 3 migration guide and release notes for more information about how to update the code to GSAP 3's syntax. 

Recommended Posts

Hello everybody


I'm working on a media gallery that uses Draggable ('rotation') to navigate. It is has many dependencies. Therefore it's hard to reproduce a simple codepen version.


But perhaps the problem rings any bells here:


Firefox refuses to handle clicks/touches correctly inside the Draggable and its sub-elements. It is ONLY FIREFOX - on all platforms. I never thought I would ever say this but: “Even IE works fine!”.
 

 

My desired Draggable settings are:

a. dragClickables:true,

b. allowEventDefault:false,

 


I get a <button> element work when I change a or b or both. Whereas <button data-clickable =”true”> does not help at all.

Whatever I do, the controls of a nested <video> never work in Firefox. Although the video works. It can be started with a right-click.


It is only the 'click' event. All other events work (rollover, mousedown...).

Even the 'click' partly works. An addEventListener ('click', funct) fires. But at the same time the CSS :active is ignored.



The script works like a charm in all other target browsers. Even on the iPhone the videos (or better their stills) smoothly rotate and you can open them.



When I disable( ) Draggable all comes back to life again.



Has anyone ever experienced this kind of trouble in Firefox? Any hint is very appreciated.

Link to comment
Share on other sites

Hi and welcome to the GreenSock forums,

 

Sorry to hear you are having troubles. It is really difficult to trouble shoot this or offer suggestions without seeing a demo. 

It would really help if you could try to reproduce it in a way that roughly simulates the way you are using it. If you get it working in a reduced demo at the very least it might help us understand where its breaking in your more complex version. If it breaks in the simple demo, than it will greatly help us in finding a fix.

  • Like 1
Link to comment
Share on other sites

Hello again

 

I made a Codepen and then another one because there was a big surprise: It works with an older Draggable version.

 

My observation is that you can't click the video controls in Firefox with version 1.18.0 (and v1.16.0 either).

However it works fine with version 1.11.6. Both examples do work in Webkit browsers.

 

Draggable v1.18.0:

See the Pen VvBVBJ by Anitainment (@Anitainment) on CodePen



Same code but Draggable v1.11.6

See the Pen yYqGaq by Anitainment (@Anitainment) on CodePen

 

I found the following difference while debugging the click event of the dragged element:

 

Draggable.min.js:14 "Capturing" (v1.18.0)

Draggable.min.js:14 "Bubbling" (v1.11.6)

 

Perhaps this is what Firefox dislikes?

 

I spend days trying to fix this Firefox problem. Usually it is my code that has to be blamed. But maybe not this time.

 

 

Cheers

 

Henry

Link to comment
Share on other sites

One more thing...

 

Please have a look at the little "Test" button below the video.
It works correctly (dragClickables:true) in Chrome but it fails in Firefox (both versions).

 

Draggable v1.18.0:

See the Pen VvBVBJ by Anitainment (@Anitainment) on CodePen

 

Draggable v1.11.6

See the Pen yYqGaq by Anitainment (@Anitainment) on CodePen

 

Thanks,

 

Henry

Link to comment
Share on other sites

  • 1 month later...

Sorry about the delay. It took some time to track down. 

 

It looks as though the core of the problem had to do with the fact that Firefox refuses to "trust" script-generated clicks, so it wouldn't allow the video to be triggered correctly by those. I believe I found a workaround though. Please try the preview of the upcoming release of Draggable: 

https://s3-us-west-2.amazonaws.com/s.cdpn.io/16327/Draggable-latest-beta.js

 

(uncompressed)

 

Does that work better for you? Can you find any other issues? 

  • Like 3
Link to comment
Share on other sites

Hello GreenSock

 

Thanks for the new beta version. I wish I could report something better but the problem remains.

I'm using your beta in the  following CodePen:

See the Pen jWEZPG by Anitainment (@Anitainment) on CodePen



I wonder why it (almost acceptably) works with older Draggable.js versions. Have you made significant changes since then?

 

 

Cheers

Henry

Link to comment
Share on other sites

Sorry for waisting your time with my cache problem. You are right. The new version works!

However, there is still one flaw when using Firefox. Below the video there is this little "Test"-button. I added some css and events to it.

See the Pen jWEZPG by Anitainment (@Anitainment) on CodePen

 

My results in Firefox are:

1) css:hover is okay

2) css:active is ignored

3) javascript: all events are okay

I can live with that. Since all events seem to work, I can force a css active state via javascript. But there is still something strange about Firefox...

 

Greetings

Henry

Link to comment
Share on other sites

Hello Jonathan

 

You were right about the typo but I'm afraid that was not the problem. I still can't see the :active state in Firefox.

 

I tested it with:

Firefox 34.0.5 (Windows 7)

Firefox 43.0b9 (Mac OS X 10.7.5)

 

Please have another look and compare the behaviour with any Webkit browser or even IE11.

See the Pen jWEZPG by Anitainment (@Anitainment) on CodePen

 

Greetings

Henry

Link to comment
Share on other sites

This could be a Firefox bug or how it behaves after an event is binded to the element.

 

http://www.w3.org/TR/CSS2/selector.html#dynamic-pseudo-classes

 

The CSS dynamic pseudo-classes spec states that:

  • An element may match several pseudo-classes at the same time.

  • CSS does not define which elements may be in the above states, or how the states are entered and left.

  • Scripting may change whether elements react to user events or not, and different devices and UAs may have different ways of pointing to, or activating elements.

  • CSS 2.1 does not define if the parent of an element that is ':active' or ':hover' is also in that state.

  • User agents are not required to reflow a currently displayed document due to pseudo-class transitions. For instance, a style sheet may specify that the 'font-size' of an :active link should be larger than that of an inactive link, but since this may cause letters to change position when the reader selects the link, a UA may ignore the corresponding style rule.

So it looks like even the CSS spec states that pseudo classes will behave differently depending on various factors including scripting, which is left up to the browser.

 

Sometime e.preventDefault() could interrupt the CSS :active, since it will be fired after the JS event, (like when using mousedown for example) and then the pseudo-class :active is fired last, after the JS event. But it looks like Firefox wont fire the pseudo :active when e.preventDefault() is used on the same element.

 

:)

  • Like 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...