5 ms·

Absolutely! The New York Times website has a similar "feature:" When the user double-clicks, the font changes size... I ended up developing an ad hoc plug-in w

Absolutely! The New York Times website has a similar "feature:" When the user double-clicks, the font changes size... I ended up developing an ad hoc plug-in which intercepts and suppresses the Event.

samfriedman 9y ago
Finally someone else who's been peeved by the Times' web reader! What's worse is that it captures mouse drag, so that I can't highlight words: dragging to the sides is hijacked to load previous/next article. Terrible design.
mkl 9y ago
Yes, this is very frustrating! I often select a word to mark my place when going off to do something else. Can you share your solution?
- trw19 9y ago
  @mkl If you use Chrome desktop then see if my above post helps .. without the need for extensions/plugins.
trw19 9y ago
It took me ages to figure out but there is a solution to this NYT website fubar that works for me on desktop browsers. In Chrome this appears to be due to the Times site responding to 'touch events' when the browser reports that the device is touch capable. When the device is touch capable the double-click-on-a-word is interpreted as a zoom attempt of sorts. And right-click doesn't work either. Even if the input was with a non-touch mouse (Or maybe they're assuming everybody is using a Mac Magic Mouse always). If you disable the touch-events-api in Chrome (chrome://flags/#touch-events) then Chrome will not report that the device is touch capable. And the NYT website will respond normally to the normal mouse interactions. This has been working for me for the past year. As for why Chrome might be claiming your input is a touch-event ... for my situation, my best guess, so far, is that this happens since the laptop has a touchpad. (My laptop doesn't have a touch-screen.) So even though I actually used an external USB mouse to interact with the browser the browser seems to report that the device is touch capable which the NYT website interprets as must-be-touch-only-always. Firefox has a similar setting called "dom.w3c_touch_events.enabled" I believe though I haven't tried this with FF. Hope that helps.

samfriedman 9y ago

Finally someone else who's been peeved by the Times' web reader! What's worse is that it captures mouse drag, so that I can't highlight words: dragging to the sides is hijacked to load previous/next article. Terrible design.

mkl 9y ago

Yes, this is very frustrating! I often select a word to mark my place when going off to do something else. Can you share your solution?

trw19 9y ago
@mkl If you use Chrome desktop then see if my above post helps .. without the need for extensions/plugins.

trw19 9y ago

It took me ages to figure out but there is a solution to this NYT website fubar that works for me on desktop browsers. In Chrome this appears to be due to the Times site responding to 'touch events' when the browser reports that the device is touch capable. When the device is touch capable the double-click-on-a-word is interpreted as a zoom attempt of sorts. And right-click doesn't work either. Even if the input was with a non-touch mouse (Or maybe they're assuming everybody is using a Mac Magic Mouse always). If you disable the touch-events-api in Chrome (chrome://flags/#touch-events) then Chrome will not report that the device is touch capable. And the NYT website will respond normally to the normal mouse interactions. This has been working for me for the past year. As for why Chrome might be claiming your input is a touch-event ... for my situation, my best guess, so far, is that this happens since the laptop has a touchpad. (My laptop doesn't have a touch-screen.) So even though I actually used an external USB mouse to interact with the browser the browser seems to report that the device is touch capable which the NYT website interprets as must-be-touch-only-always. Firefox has a similar setting called "dom.w3c_touch_events.enabled" I believe though I haven't tried this with FF. Hope that helps.