854072 - Press and hold on empty space brings up nonsensical selection

Status: RESOLVED INCOMPLETE

(Firefox for Metro Graveyard :: Input, defect, P2)

Description

[Jim Mathies [:jimm]]

str:

- press hold on background content 

result: 
- selection monocles are displayed bordering nonsensical content
- context menu is displayed with 'copy' and pointless 'search bing for ""' options

expected:
- nothing should happen

Comment 1

[Brian R. Bondy [:bbondy]]

Defect for it5?

Comment 2

[Marco Mucci [:MarcoM]]

Moving to iteration #5 for consideration as a defect.

Comment 3

[Jim Mathies [:jimm]]

Attachment: example regions

I'm not sure how to solve this. What we want to be able to do in ContextMenuHandler is make a smart choice about whether or not the user intended to invoke selection on underlying text content.

http://mxr.mozilla.org/mozilla-central/source/browser/metro/base/content/contenthandlers/ContextMenuHandler.js#220

The popup dom node is commonly an element type. If we instance of test it it can be anything depending on the underlying content. I have a test case where I have form inputs that run down the left side of a page an if I press-hold in the empty content to the right, I get a form element. In the test case pictured here I get a div. So I don't think the element type is of much help.

What I need to be able to do is ask the dom "hey, is there selectable content near this point?" but afaik we don't have anything like that available.

cc'ing a few folks who might have some ideas.

Comment 4

[Wesley Johnston (:wesj)]

My plan for Fennec was to do something like:

if (DOMWindowUtils.selectAtPoint()) {
  var rects = getSelection().getRangeAt(0).getBoundingClientRect(); // I hope this is a 0x0 rect at some point?
  // if point is near rects, continue selection, otherwise cancel it
}

Comment 5

[Jim Mathies [:jimm]]

(In reply to Wesley Johnston (:wesj) from comment #4)
> My plan for Fennec was to do something like:
> 
> if (DOMWindowUtils.selectAtPoint()) {
>   var rects = getSelection().getRangeAt(0).getBoundingClientRect(); // I
> hope this is a 0x0 rect at some point?
>   // if point is near rects, continue selection, otherwise cancel it
> }

That would work in the test case I have, although I think you might see a brief flash of selection rendered after calling selectAtPoint. In the screenshot I posted, the selection would be some random chunk of the text to the left of where you placed your finger.

Comment 6

[Jim Mathies [:jimm]]

Attachment: example selection w/selectAtPoint

Maybe selectAtPoint can be trained to be more 'selective' than this. Although I'd prefer to find a solution that doesn't involve mucking with c++ selection code. :)

Comment 7

[Wesley Johnston (:wesj)]

True. In fennec, our selection starts by positioning the cursor with a mouse click, which is horrible, but also invisible (and hopefully all those hacks are going away). I assumed nothing would show.

Comment 8

[Jim Mathies [:jimm]]

Attachment: forms fix

We can avoid this in certain cases (like my test case) by being more careful about when we call selectAtPoint.

Comment 9

[Jim Mathies [:jimm]]

Attachment: forms fix

Comment 10

[Marco Mucci [:MarcoM]]

Point Estimate = 8.

Comment 11

[Firefox Bug Husbandry Bot]

Mass close of bugs in obsolete product https://bugzilla.mozilla.org/show_bug.cgi?id=1350354