12221 - [Dogfood] Gfx text controls need to notify on mouse events

Status: VERIFIED FIXED

(Core :: DOM: Selection, defect, P2)

Description

[cpratt]

Build ID: 1999082008
Platform: all

To reproduce:

- Launch apprunner
- Select the URL displayed in the Location: control in this manner:

 -------------------------------------------------------------------
| http://www.yahoo.com *                                         ^  |
 -------------------------------------------------------------------

Pretend that my ASCII art represents the Location: control in the browser.

In legacy browsers, if you position the cursor at the caret (^), click and hold
the mouse button, and drag to the left, the entire URL will be selected.
However, this fails in apprunner. Instead, you have to position the cursor
immediately to the right of the URL (marked here by an asterix (*)). This is a
major usability problem.

Comment 1

[buster]

known problem, assigned to mike.

Comment 2

[mjudge]

pretty much done. tables still have an issue though. working on this. its a dup
of a feature for clicking in dead zones. will keep this alive until tables work.

Comment 3

[mjudge]

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

Comment 4

[Michael Lowe]

In the build I have (25/08), there seems to be some problems with the current
implementation on some of the text in demo 0 & 1 (and maybe others).

Comment 5

[Eli Goldberg]

Since this is a selection issue, QA Assigning to self, CC:ing Sujay, and changing
component.

Comment 6

[mjudge]

works now, or at least it should.

Comment 7

[Eli Goldberg]

Re-opening; it will not allow you to drag select from the ~10 pixel region to the
left of the URL text, despite displaying an i-beam. (1999091409 builds checked on
Mac OS & Win32, and 1999 09/13 build on Linux)

Comment 8

[leger]

Clearing FIXED resolution due to reopen of this bug.

Comment 9

[Kathleen :Brade]

m12; kin

Comment 10

[kinmoz]

Accepting bug.

Comment 11

[kinmoz]

When you click on the edge of the location control (^), the button down event is
actually going to the GFXTextControlFrame which does nothing with it.

We need to add some sort of mouse listener, or some code to
GFXTextControlFrame::HandleEvent() that will forward on mouse events to the
inner presShell so that the text control's inner document can process it.

Reassigning to [e-mail], the author of the GFXTextControlFrame code.

Comment 12

[kinmoz]

Added [e-mail] to the Cc list.

Comment 13

[buster]

all the code is there, just commented out because mouse
notifications are non-standard behavior for HTML text controls.  But that
doesn't mean we can't use it internally.  Will turn it on as soon as the tree
opens.

Comment 14

[leger]

Putting on [PDT]+ radar.

Comment 15

[buster]

fixed
r=[e-mail]
also did some associated performance work, factoring code and collapsing
multiple listener objects down to 1.  This saves a few allocations and about 60
bytes per text control.

Comment 16

[Eli Goldberg]

Verified fixed on 1999102008 (Mac OS, 8.6), 1999101908 (Win32, NT 4.0SP5), and
1999101908 (Linux, RH 6.0/GNOME).

Specifically, performed the instructions detailed in the bug report, as well as
double- and triple-clicking.

----

I noticed a very small nitpick, in which clearing the URL entire text field (on
all platforms) and double-clicking in it will still result in the first character
being highlighted.

Since this doesn't occur on IE or Navigator, I'm going to write it up as a
formality, and will note the bug number here.

Comment 17

[Eli Goldberg]

[Nitpick broken into 16905.]

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/675ed48b02cc
[fenix] Migrate from Session.toTab to BrowserStore (https://github.com/mozilla-mobile/fenix/pull/12221)