301873 - middle click into vert. scroll bar tries to open X-selection if JavaScript is disabled

Status: RESOLVED FIXED

(Core :: General, defect)

Description

[Franz]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.7.10) Gecko/20050717 Firefox/1.0.6
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.7.10) Gecko/20050717 Firefox/1.0.6

middle mouse click used to put the slider to the position of the mouse pointer
and adjust the page accordingly.

If you disable javascript ff tries to open the content of the X-selection.

Reproducible: Always

Steps to Reproduce:
1. select a page with vertical scrollbar and mark some text (put it in the
   X-selection)
2. click middle mouse button (wheel) into scrollbar but not on the slider
3. disable JavaScript
4. click again

Actual Results:  
First the slider position is adjusted and immediately ff tries to
open an url from the content of the X-selection.

Expected Results:  
Behave consistently (like ff 1.0.4), i. e. adjust page/slider regardless of
JavaScript enabledness.

Comment 1

[Andrew Schultz]

regressed on trunk between seamonkey builds 2005070502 and 2005070605.  that and
the regression stated here between 1.7.8 and 1.7.10 indicates this from bug 298934.

==> DOM

Comment 2

[Andrew Schultz]

*** Bug 311271 has been marked as a duplicate of this bug. ***

Comment 3

[Daniel Veditz [:dveditz]]

bug 298934 is an extremely unlikely cause for this: the entire fix was limited
to the nsGlobalWindow::MakeScriptDialogTitle() function and I can't see how that
would be involved with scrollbar clicking, let alone when JS is *off*.

Isn't it more likely to be bug 298892, or something fundamental like bug 299450?
Or, if you're off a day with your regression window, the middle-click bug 299901?

Comment 4

[Andrew Schultz]

> bug 298934 is an extremely unlikely cause for this:

indeed.  I didn't notice all the other a= checkins in that range.  Backing out
bug 298892 didn't help (neither did backing out bug 298934).  Backing out bug
299450 failed (too many changes since then) (why is that bug still closed?). 
And I just rechecked and my 2005070605 and it's definitely affected by this.  So
bug 299450 seems like the most likely candidate.

Comment 5

[Andrew Schultz]

oh, and the symptom of this perhaps deeper bug is gone in current trunk builds.
 It disappeared between builds 2005100701 and 2005100805, probably bug 70698.

Comment 6

[Boris Zbarsky [:bzbarsky]]

This is a regression from bug 298892 -- it removed the line in contentAreaClick
that prevented the middle-click behavior with the justification that
"scrollbar.xml blocks clicks on scrollbars".  But scrollbar.xml is not allowed
to execute script if JS is disabled, since the scrollbar is part of the
untrusted content area, so scrollbar.xml is running with content privileges.

The worst thing is that this change was landed on the 1.7 branch too....

We need to restore that scrollbar check on all three branches (1.7, aviary,
1.8).   Or take trhe trunk approach of using preventdefault="true" in the XBL if
that approach works on 1.7 branch.

Comment 7

[Asa Dotzler [:asa]]

Neil or Mike, can one of you come up with a patch today? Time is very short.

Comment 8

[[e-mail]]

Attachment: Proposed patch

This contains the toolkit change from the AVIARY_1_0_1_20050124_BRANCH and the
xpfe change from the MOZILLA_1_7_BRANCH so be careful when checking in.

I consolidated the preventdefault attribute with the preventDefault() action.

Comment 9

[Asa Dotzler [:asa]]

Comment on attachment 199358 [details] [diff] [review]
Proposed patch

Mike, can you review and help shephard this in?

Comment 10

[Scott MacGregor]

Let's get this checked into the trunk for baking ASAP and then nominate for
branch approval after we've verified it on the trunk. 

Comment 11

[[e-mail]]

(In reply to comment #10)
>Let's get this checked into the trunk for baking ASAP and then nominate for
>branch approval after we've verified it on the trunk.
This never regressed on trunk because of bug 70698 also patched scrollbar.xml

Comment 12

[[e-mail]]

Comment on attachment 199358 [details] [diff] [review]
Proposed patch

Sorry, I misunderstood comment 5; a side-effect of bug 70698 happened to fix
this bug on the trunk. If you prefer I can check in parts of that patch
instead.

Comment 13

[Ian Collier]

I don't know if it's relevant, but this seems to affect textarea boxes on web
pages too (such as the one I'm typing this comment into).  Middle-click into the
textarea's scrollbar, and the clipboard will be pasted into the textarea at the
current cursor position.

I attempted to retrofit the patch in attachment 199358 [details] [diff] [review] to my running copy of
Mozilla 1.7.12 by editing the file content/global/bindings/scrollbar.xml within
chrome/toolkit.jar.  It fixed the main window scrollbar, but the problem with
textarea boxes remains.  That might just mean I'm attempting the wrong thing, of
course.

Comment 14

[[e-mail]]

(In reply to comment #13)
>It fixed the main window scrollbar, but the problem with textarea boxes remains. 
Unfortunately that needs the complete fix from bug 70698, which seems unlikely.

Comment 15

[Asa Dotzler [:asa]]

Comment on attachment 199358 [details] [diff] [review]
Proposed patch

we'll evaluate for 1.7.13 when we're triaging those requests. a=asa for the 1.8
branch. please add the "fixed1.8" keyword when you land this on the branch.
Thanks for the quick turnaround.

Comment 16

[Daniel Veditz [:dveditz]]

Comment on attachment 199358 [details] [diff] [review]
Proposed patch

a=dveditz for drivers, please add fixed-aviary1.0.8 and fixed1.7.13 keywords when checked in.

Comment 17

[Tracy Walker [:tracy]]

verified with:
Linux
Moz - Mozilla/5.0 (X11; U;Linux i686; en-US; rv:1.7.13) Gecko/20060214
Fx -  Mozilla/5.0 (X11; U;Linux i686; en-US; rv:1.7.13) Gecko/20060214 Firefox/1.0.8

Comment 18

[Ian Collier]

Main issue is verified fixed on:
Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7.13) Gecko/20060509

but the problem with scrollbars in textareas remains.

Comment 19

[[e-mail]]

(In reply to comment #18)
>but the problem with scrollbars in textareas remains.
Is there an echo in here?