308503 - middle mouse clicks partly broken

Status: RESOLVED FIXED

(SeaMonkey :: UI Design, defect)

Description

[R.K.Aa.]

20050913 SeaMonkey/1.1a

when clicking with the middle button (scrollwheel click) i get a square "scroll
icon" when i try to middle-mouse paste in forms or scroll on slidebar.
This has happened the last week and I consider it a major annoyance and
usability setback

My prefs are:

greprefs/all.js:
pref("middlemouse.scrollbarPosition", true);

prefs.js:
user_pref("middlemouse.paste", true);

Comment 1

[R.K.Aa.]

BZ: Using WinXP and seeing this regression with
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050913
SeaMonkey/1.1a (Build ID 2005091306)

Comment 2

[R.K.Aa.]

was OK in 2005070906 and broken in 2005071005

Comment 3

[R.K.Aa.]

sorry.. broke between 9th and 10th this month
broke in 2005091005

Comment 4

[R.K.Aa.]

the scrollbar in mailnews is not affected

Comment 5

[R.K.Aa.]

oops..  i'm wrong. Hold it, i'll find the correct regression window

Comment 6

[R.K.Aa.]

OK - I've triple checked, full installs/uninstalls:

Trunk Semonkey 2006090406 is the last OK build.
There's a gap in builds - none for the 5th and 6th.
The next one, 2005090705, is where this is broken.

Full installs from seamonkey-1.1a.en-US.win32.installer.exe

Comment 7

[R.K.Aa.]

There's another bug in 2004090406 which is GONE in later builds;
the personal toolbar folders can not be opened in new windows.
But if i middle-mouse click them, all content in the folders opens in new tabs.

That was earlyer reported as bug 307115, resolved as WFM without pointers to the
fix.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Sounds like bug 304563 to me.

Comment 9

[R.K.Aa.]

yes, we mid-aired twice lol

Comment 10

[Robert Kaiser]

removing blocking-seamonkey1.0a request. Please only re-request if that can be
confirmed in branch builds as well, which I seriously doubt as autoscroll hasn't
landed on trunk, IIRC...

Comment 11

[Boris Zbarsky [:bzbarsky]]

re-requesting, since autoscroll has branch approval and presumably will land
there and I really don't have the time to watch the branch for it.

Comment 12

[:deanis74]

Is this as simple this change in contentAreaClick.js (based on attachment 194451 [details] [diff] [review])?

    if (event.button == 1 && !hrefAndLinkNodeForClickEvent(event)
-       && (!pref || !pref.getBoolPref("middlemouse.contentLoadURL"))
+       && (!pref || !pref.getBoolPref("middlemouse.contentLoadURL") ||
+           !pref.getBoolPref("middlemouse.scrollbarPosition") ||
+           !pref.getBoolPref("middlemouse.paste"))
        && (event.target != event.currentTarget)) {

Comment 13

[:deanis74]

Assigning to CTho.  Chris, see the above suggestion.

Comment 14

[Robert Kaiser]

bz, in this case moving to beta, as alpha has been tagged and autoscroll is not
in that one.

Comment 15

[Boris Zbarsky [:bzbarsky]]

Wouldn't that disable autoscroll altogether if those prefs are set?  I'd think
that for middlemouse.scrollbarPosition we want to autoscroll as long as it's not
a scrollbar being clicked on...

Comment 16

[R.K.Aa.]

i found that a pref for disabling autoscroll was addedin Firefox already 2 years
ago. Perhaps something there worth looking at: bug 212000. It would be highly 
annoying not to be able to get rid of it alltogether..

Comment 17

[:deanis74]

Toolkit has isAutoScrollBlocker in browser.xml.  Isn't this what we're looking for?

http://lxr.mozilla.org/mozilla/source/toolkit/content/widgets/browser.xml#689

Comment 18

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

I'm not sure what the "scrollbarPosition" pref does (make scrollbars act like
they do in weird old X apps?).  I can't seem to detect when you middle click on
a scrollbar (the FF code doesn't work for me), and the scrollbars don't show up
in DOMI, so I don't know how to handle the scrollbar stuff.  The
middlemousepaste is easy to fix, but it'll have to wait until I can get info
about scrollbarPosition.

Clearing the blocking? flag.  I won't land any autoscroll on branch unless this
is fixed, so blocking+ would be blocking for a feature, which I'm told we don't do.

Comment 19

[[e-mail]]

(In reply to comment #17)
>Toolkit has isAutoScrollBlocker in browser.xml.  Isn't this what we're looking for?
Roughly, but incorrect for xlinks and arbitrary input elements - you can tell
which because pastable inputs have controllers, and you could even use
target.controllers.getControllerForCommand('cmd_paste').isCommandEnabled('cmd_paste')
to see if there is anything to paste (into).

(In reply to comment #18)
>I'm not sure what the "scrollbarPosition" pref does (make scrollbars act like
>they do in weird old X apps?).
Have you not shift-clicked a scrollbar recently (gecko or w2k+)? (For more fun
in w2k+ try right-clicking a scrollbar.)

>the scrollbars don't show up in DOMI
No, but they will still be the original target of mouse event - you should see
one of scrollbarbutton slider thumb or scrollcorner. You can find a scrollbar in
DOMI by inspecting a XUL tree (or write your own scrollbar testcase).

Comment 20

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

Fixed by second checkin for bug 304563.