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
Product: Firefox → Core
QA Contact: general → ian
Version: unspecified → Trunk
*** 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?
> 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
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
Component: DOM → XP Miscellany
QA Contact: ian → brendan
13 years ago
Assignee: nobody → neil.parkwaycc.co.uk
Neil or Mike, can one of you come up with a patch today? Time is very short.
Flags: blocking1.8rc1? → blocking1.8rc1+
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 on attachment 199358 [details] [diff] [review] Proposed patch Mike, can you review and help shephard this in?
Attachment #199358 - Flags: review?(mconnor)
Attachment #199358 - Flags: review?(mconnor) → review+
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.
(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
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.
(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 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+
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.
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
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.
(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.
You need to log in before you can comment on or make changes to this bug.