Resizing the "comment" textarea on the new attachment page (bugzilla) is interrupted by moving the cursor outside the bounds of the resize icon.

VERIFIED FIXED in Firefox 18

Status

()

defect
VERIFIED FIXED
7 years ago
6 years ago

People

(Reporter: johan.charlez, Assigned: mats)

Tracking

({regression})

18 Branch
mozilla19
Points:
---

Firefox Tracking Flags

(firefox18+ verified, firefox19+ verified)

Details

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

7 years ago
Reproduced on:
Windows 7 64-bit
Ubuntu

Reproduced in:
Firefox Aurora 18
Firefox Nightly 19

Works as expected in:
Chrome 22
Firefox Beta 17 (Built from http://hg.mozilla.org/releases/mozilla-beta/rev/6b83222781e3)

STR:
1. Browse to any bug on bugzilla.mozilla.org
2. Click "Add an attachment".
3. Scroll down to the "comment" textarea and attempt to resize it.
3.1: Click and drag the "resize icon".

Expected result:
Resizing the textarea works fine.

Actualy result:
It is possible to resize the textarea, but as soon as the mouse cursor moves outside the "bounds" of the "resize icon", resizing is interrupted. Move the mouse cursor back over the "resize icon" again and resizing is resumed (without having to click and drag again).

Comment 1

7 years ago
Regression window(m-i)
Good:
http://hg.mozilla.org/integration/mozilla-inbound/rev/3c1d23fe3275
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 ID:20120907044033
Bad:
http://hg.mozilla.org/integration/mozilla-inbound/rev/0f994df8c6c4
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 ID:20120907075236
Pushlog;
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=3c1d23fe3275&tochange=0f994df8c6c4

Suspected: Bug 786946

WORKAROUND:
select{
  display: inline !important;
}
Blocks: 786946
Keywords: regression

Comment 2

7 years ago
Posted file not reduced html (obsolete) —
That's ... very odd.  That bug should have changed nothing about this behavior.

Furthermore, I can't reproduce this (on Mac, though).

Alice0775, are you sure about the regression range?
Component: DOM: Core & HTML → Widget

Comment 4

7 years ago
(In reply to Boris Zbarsky (:bz) from comment #3)
> That's ... very odd.  That bug should have changed nothing about this
> behavior.
> 
> Furthermore, I can't reproduce this (on Mac, though).
> 


I can reproduce on ubuntu as well.
http://hg.mozilla.org/releases/mozilla-aurora/rev/46d6d05da75e
Mozilla/5.0 (X11; Linux i686; rv:18.0) Gecko/18 Firefox/18.0a2 ID:20121021042011

> Alice0775, are you sure about the regression range?

Sure.

Comment 5

7 years ago
Posted file Reduced testcase
This testcase shows that a <select> before the <textarea> causes the textarea resizing to fail. It is important that the <select> be scrolled up so that it is not visible. I added a margin on the <textarea> to make this easier.

This testcase fails evens with the change from 786946 removed.

Note also that mouse capture doesn't get turned off when a mouseup occurs after resizing.
Attachment #673709 - Attachment is obsolete: true
OK, I can't reproduce on Linux either, in today's nightly....

Just to make sure I'm doing the right steps, here's what I do:

1)  Load the "Add an attachment" page for this bug
2)  Scroll down to the "comment" textarea
3)  Mouse down on the little shaded triangle (resize handle) in the bottom right of the
    textarea
4)  Move the mouse up above the top edge of the textarea, so it ends up outside the
    resize handle.
5)  Move the mouse left and right and observe that the textarea continues resizing in
    the horizontal direction.
6)  Release mouse, move mouse over resize handle, observe that the textarea is not
    resizing.

which is all as expected, I think...
Attachment #673980 - Attachment is patch: false
Attachment #673980 - Attachment mime type: text/plain → text/html
OK, on Neil's testcase I can reproduce if I make the textarea large enough vertically that I can scroll the <select> off the top edge of the screen...

Comment 8

7 years ago
For my testcase, I could not reproduce in firefox 15 but can do in 16.
It sounds like the main impact of bug 786946 might have been changing the sizes of some things at some resolutions on some systems so that <select> elements ended up offscreen?

Comment 10

7 years ago
FYI, I test again using attachment 673980 [details]

Regression wndow(m-c)
Good:
http://hg.mozilla.org/mozilla-central/rev/bf37951c1104
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0a1 ID:20120623031143
Bad:
http://hg.mozilla.org/mozilla-central/rev/e21173ed2c38
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0 ID:20120623053647
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=bf37951c1104&tochange=e21173ed2c38

Regression wndow(m-i)
Good:
http://hg.mozilla.org/integration/mozilla-inbound/rev/80b8680bda1c
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0 ID:20120622175046
Bad:
http://hg.mozilla.org/integration/mozilla-inbound/rev/c35d2d3071ac
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0 ID:20120622182843
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=80b8680bda1c&tochange=c35d2d3071ac


Triggered by:
23f5c88adb8f	Mats Palmgren — Bug 575294. part=2/5 r=smaug,roc
Blocks: CVE-2012-3984
No longer blocks: 786946

Comment 11

7 years ago
Maybe Mats can take a look.
Mats, passing this on to you as Bug 575294 could be a suspecting regressing bug
Assignee: nobody → matspal
(Assignee)

Comment 13

7 years ago
The reason for this is nsListControlFrame::CaptureMouseEvent:
http://hg.mozilla.org/mozilla-central/annotate/a5ab93cf9fea/layout/forms/nsListControlFrame.cpp#l834
which calls SetCapturingContent(nullptr, 0) even if the content doesn't
match (in case IsDroppedDown() is false).  This seems wrong but I guess
it is (or was?) needed.  Anyway, we shouldn't call it in the first place.
Attachment #676733 - Flags: review?(roc)
(Assignee)

Comment 14

7 years ago
Posted patch wdiffSplinter Review
https://hg.mozilla.org/mozilla-central/rev/3781f04d144d
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla19
(Assignee)

Comment 17

7 years ago
Comment on attachment 676733 [details] [diff] [review]
Dispatch an nsAsyncRollup event (that calls RollupFromList) only if we're dropped down since otherwise it might reset mouse capturing for other content.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Bug 575294
User impact if declined: resizing text areas is "sticky", non-functional, on pages with a combobox scrolled out of view
Testing completed (on m-c, etc.): on m-c since 2012-10-31
Risk to taking this patch (and alternatives if risky): low risk
String or UUID changes made by this patch: none
Attachment #676733 - Flags: approval-mozilla-aurora?
Adding qawanted to help verify, while it gets some bake time on central before approving.
Keywords: qawanted
Verified on latest nightly across OSs using the testcase from comment #5.
Comment on attachment 676733 [details] [diff] [review]
Dispatch an nsAsyncRollup event (that calls RollupFromList) only if we're dropped down since otherwise it might reset mouse capturing for other content.

Approving for aurora, as it is tracking 18, low risk and verified by QA
Attachment #676733 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Verified fixed FF 18b5 Windows 7 x64, Ubuntu x86 and Mac OS 10.8. 

Works as expected, after mouse cursor moves outside the "bounds" of the "resize icon", resizing is not interrupted.

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0 (20121219074241)
Mozilla/5.0 (X11; Linux i686; rv:18.0) Gecko/20100101 Firefox/18.0 (20121219074241)
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:18.0) Gecko/20100101 Firefox/18.0 (20121219074241)
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.