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

RESOLVED FIXED

Status

()

RESOLVED FIXED
13 years ago
10 years ago

People

(Reporter: franz.gans, Assigned: neil)

Tracking

({fixed1.8, regression, verified1.7.13})

1.7 Branch
x86
Linux
fixed1.8, regression, verified1.7.13
Points:
---
Bug Flags:
blocking1.7.13 +
blocking-aviary1.0.8 +
blocking1.8rc1 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: Bug is only partially fixed on 1.7 branch. We know about this.)

Attachments

(1 attachment)

(Reporter)

Description

13 years ago
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

13 years ago
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
Assignee: nobody → general
Status: UNCONFIRMED → NEW
Component: General → DOM
Depends on: 298934
Ever confirmed: true
Keywords: regression
Product: Firefox → Core
QA Contact: general → ian
Version: unspecified → Trunk

Comment 2

13 years ago
*** Bug 311271 has been marked as a duplicate of this bug. ***
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

13 years ago
> 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.
No longer depends on: 298934

Comment 5

13 years ago
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.
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.
Assignee: general → nobody
Blocks: 298892
Component: DOM → XP Miscellany
Flags: blocking1.8rc1?
Flags: blocking1.7.13?
Flags: blocking-aviary1.0.8?
QA Contact: ian → brendan
Assignee: nobody → neil.parkwaycc.co.uk

Comment 7

13 years ago
Neil or Mike, can one of you come up with a patch today? Time is very short.
Flags: blocking1.8rc1? → blocking1.8rc1+
(Assignee)

Comment 8

13 years ago
Created attachment 199358 [details] [diff] [review]
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

13 years ago
Comment on attachment 199358 [details] [diff] [review]
Proposed patch

Mike, can you review and help shephard this in?
Attachment #199358 - Flags: review?(mconnor)

Updated

13 years ago
Attachment #199358 - Flags: review?(mconnor) → review+

Comment 10

13 years ago
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. 
(Assignee)

Comment 11

13 years ago
(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
Version: Trunk → 1.7 Branch
(Assignee)

Comment 12

13 years ago
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.
Attachment #199358 - Flags: approval1.8rc1?
Attachment #199358 - Flags: approval1.7.13?

Comment 13

13 years ago
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.
(Assignee)

Comment 14

13 years ago
(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

13 years ago
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.
Attachment #199358 - Flags: approval1.8rc1? → approval1.8rc1+
(Assignee)

Updated

13 years ago
Keywords: fixed1.8

Updated

13 years ago
Whiteboard: [needs approval]
Flags: blocking1.7.13?
Flags: blocking1.7.13+
Flags: blocking-aviary1.0.8?
Flags: blocking-aviary1.0.8+
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.
Attachment #199358 - Flags: approval1.7.13?
Attachment #199358 - Flags: approval1.7.13+
Attachment #199358 - Flags: approval-aviary1.0.8+
(Assignee)

Updated

13 years ago
Keywords: fixed-aviary1.0.8, fixed1.7.13
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
Keywords: fixed-aviary1.0.8, fixed1.7.13 → verified-aviary1.0.8, verified1.7.13

Comment 18

12 years ago
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.
(Assignee)

Comment 19

12 years ago
(In reply to comment #18)
>but the problem with scrollbars in textareas remains.
Is there an echo in here?
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
Whiteboard: [needs approval] → Bug is only partially fixed on 1.7 branch. We know about this.

Updated

10 years ago
Component: XP Miscellany → General
QA Contact: brendan → general
You need to log in before you can comment on or make changes to this bug.