User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:56.0) Gecko/20100101 Firefox/56.0 Build ID: 20170615030208 Steps to reproduce: From my WebExtensions addon I would like to disable/enable autoscrolling dynamically. This would allow the middle click mouse button to do different things, for example close the current tab if https://addons.mozilla.org/en-US/firefox/addon/middle-click-on-page-close-tab/ is installed. Right now this is very hacky thing to do. Expected results: I would like an API that allows disabling and enabling autoscrolling. This can be implemented globally or per page.

This is turn off-able in about:preferences > General > Browsing > Use autoscrolling. Let's pass this to the design meeting. If this was enabled, we'd need to a corresponding bug to about:preferences and Project Jazz to show this information to the user.

(In reply to Andy McKay [:andym] from comment #1) > This is turn off-able in about:preferences > General > Browsing > Use > autoscrolling. Correct. > Let's pass this to the design meeting. If this was enabled, we'd need to a > corresponding bug to about:preferences and Project Jazz to show this > information to the user. Thanks for triaging it so quickly. An API for this is also useful for TabCenter Redux (and probably other sidebar extensions which handle middle mouse button clicks).

Hi Geoffrey, this has been added to the agenda for the June 25 WebExtensions APIs triage meeting. Would you be able to join us? Wiki: https://wiki.mozilla.org/Add-ons/Contribute/Triage#Next_Meeting Agenda: https://docs.google.com/document/d/1BBIZhiHG1zlQiu6744jiAYyWJLa-B0iRu9vzWypkvF4/edit#

From the discussion, we'd rather not add more pref flipping if possible. The base issue is being able to handle the middle click, but it seems auto-scroll interferes with that. We should figure out if there is a way to handle that without the pref flip, otherwise I think we should probably support the pref flip. I'll try to find someone with more knowledge on that area.

You can currently change the middle mouse behaviour. To disable autoscrolling and do something else, you need this: w.addEventListener("click", eventHandler); w.addEventListener('mousedown', cancelEvent); w.addEventListener("mouseup", cancelEvent); Problem with this approach is that you can no longer use autoscrolling anywhere. So I want to allow autoscrolling and both my custom action. I do this by calculating the time difference between the mouseup and mousedown event when I enter the mouseup event handler. If the user clicked fast enough (within 200ms) I close the tab, otherwise I assume the user wants to autoscroll. (this timeout is configurable in my addon) This does work and closes the tab if the user is fast enough. This works because I haven't canceled any events (click, mousedown or mouseup) in this case. However, the autoscrolling icon becomes visible and there is no way to programmatically stop autoscrolling (when it has already started). The only thing that helps is a click iniated by the user to stop the autoscrolling (the user gets the impression the addon STEALS a click on a UI tab or HTML element in the content page). A programmatic click from within the content script does not work. If there is a workaround which does stop autoscrolling when it has started (when I didn't want it to), I would be very delighted to hear about it.

Source code is here: https://github.com/Smile4ever/firefoxaddons/tree/master/Middle%20Click%20On%20Page%20Closes%20Tab-webext (middleclick.js)

billm: I noticed you touched some autoscroll stuff in the past, particularly bug 938359. Wondering if you have thoughts on this bug and how we might avoid pref flipping to support middle click handling.

I'm confused about the use case here. As best I can understand, the add-on works as follows: 1. When the user middle clicks, it checks if it's a short click or a long click (based on the duration between mousedown and mouseup). 2. If it's a short click, the tab is closed. 3. If it's a long click, autoscrolling engages. It seems like this works as desired. If users don't like the behavior in step 3, can't they just turn off autoscrolling themselves?

Seems like this can be re-evaluated now that we have the browserSettings API.

(In reply to Tim Nguyen :ntim from comment #9) > Seems like this can be re-evaluated now that we have the browserSettings API. We had the browserSettings API when this was first discussed, so I'm not sure that changes anything. It doesn't seem like there's been a response since billm's comment 8, so I think we're waiting on that.

(In reply to Bill McCloskey (:billm) from comment #8) > I'm confused about the use case here. As best I can understand, the add-on > works as follows: > 1. When the user middle clicks, it checks if it's a short click or a long > click (based on the duration between mousedown and mouseup). > 2. If it's a short click, the tab is closed. > 3. If it's a long click, autoscrolling engages. > > It seems like this works as desired. If users don't like the behavior in > step 3, can't they just turn off autoscrolling themselves? The problem is the autoscrolling icon is shown at step 2, while it shouldn't be shown (because we are closing the tab - the autoscrolling icon does not go away after closing the tab). The canceling of the autoscrolling event (so the icon isn't shown anymore) can only occur in mousedown, but to calculate the duration of the click, you need to wait for mouseup. I tried to make the autoscrolling icon go away by creating synthetic key events, but that does not have the desired effect. Only when the user of the addon clicks on the page, the icon appears and the click is "eaten": if the user clicked on a link, the autoscrolling icon disappears but the link is not opened. A solution would be to stop autoscrolling once the page closes. How do you like that solution? Or have you thought of other solutions, billm?

> A solution would be to stop autoscrolling once the page closes. Geoffrey, is that all that is needed here? If so, I think this is just a bug rather than design decision. ni me if that's the case.

(In reply to Shane Caraveo (:mixedpuppy) from comment #12) > > A solution would be to stop autoscrolling once the page closes. > > Geoffrey, is that all that is needed here? If so, I think this is just a > bug rather than design decision. ni me if that's the case. You might consider it a bug, since autoscrolling should be page specific: - if you reload the page programmatically the autoscrolling icon should go away - if you close the tab programmatically the autoscrolling icon should go away - setting the focus/calling the click event programmatically on any HTML element should also remove the autoscrolling icon (like with manual focusing) - with any key event (even synthetic ones) - maybe except for the arrow keys - the autoscrolling icon should go away The autoscrolling icon does not go away in Middle Click On Page Closes Tab because I don't cancel the autoscrolling in the mouseDown handler. I do this to be able to calculate the time difference between the mouseDown and mouseUp events (and depending on that, continue with autoscrolling or close the current tab). Since I cannot technically cancel the autoscrolling in the mouseUp handler, the autoscrolling icon stays around while I don't want it there anymore (I closed the tab, and the icon is still visible!). From a technical standpoint, two good, complementary solutions come to mind: - make e.preventDefault() in mouseUp always cancel the autoscrolling - cancel the autoscrolling upon closing or reloading a tab If you need more info or feedback, needinfo me.

(In reply to Geoffrey De Belie (Smile4ever) from comment #13) > (In reply to Shane Caraveo (:mixedpuppy) from comment #12) > > > A solution would be to stop autoscrolling once the page closes. > > > > Geoffrey, is that all that is needed here? If so, I think this is just a > > bug rather than design decision. ni me if that's the case. > From a technical standpoint, two good, complementary solutions come to mind: > - make e.preventDefault() in mouseUp always cancel the autoscrolling > - cancel the autoscrolling upon closing or reloading a tab I don't know enough about autoscroll to know if the first is a good idea or not, but the second certainly sounds like a bug. Added bug 1446484.