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.

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.

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?

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