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

Status: VERIFIED FIXED

(Core :: Widget, defect)

Description

[Johan C]

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

[Alice0775 White]

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;
}

Comment 2

[Alice0775 White]

Attachment: not reduced html

Comment 3

[Boris Zbarsky [:bzbarsky]]

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?

Comment 4

[Alice0775 White]

(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

[Neil Deakin]

Attachment: 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.

Comment 6

[Boris Zbarsky [:bzbarsky]]

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...

Comment 7

[Boris Zbarsky [:bzbarsky]]

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

[Neil Deakin]

For my testcase, I could not reproduce in firefox 15 but can do in 16.

Comment 9

[Boris Zbarsky [:bzbarsky]]

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

[Alice0775 White]

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

Comment 11

[Neil Deakin]

Maybe Mats can take a look.

Comment 12

[bhavana bajaj [:bajaj]]

Mats, passing this on to you as Bug 575294 could be a suspecting regressing bug

Comment 13

[Mats Palmgren (inactive)]

Attachment: Dispatch an nsAsyncRollup event (that calls RollupFromList) only if we're dropped down since otherwise it might reset mouse capturing for other content.

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.

Comment 14

[Mats Palmgren (inactive)]

Attachment: wdiff

Comment 15

[Mats Palmgren (inactive)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/3781f04d144d

Comment 16

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/3781f04d144d

Comment 17

[Mats Palmgren (inactive)]

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

Comment 18

[bhavana bajaj [:bajaj]]

Adding qawanted to help verify, while it gets some bake time on central before approving.

Comment 19

[juan becerra [:juanb]]

Verified on latest nightly across OSs using the testcase from comment #5.

Comment 20

[bhavana bajaj [:bajaj]]

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

Comment 21

[Mats Palmgren (inactive)]

https://hg.mozilla.org/releases/mozilla-aurora/rev/4af5edaf6385

Comment 22

[Mihai Morar, (:MihaiMorar)]

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)