1495482 - Invalid anchorNode when the caret is inside input[type="number"]

Status: RESOLVED DUPLICATE of bug 981248

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

Description

[Alexander Ebert]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.35 Safari/537.36

Steps to reproduce:

Firefox 62 (64-Bit) on Windows 10 (x64)

1. Create an input field that accepts numbers:
<input type="number">
2. Place the caret inside the input field, clicking into it to focus it will do.
3. Open the console and execute this statement:
getSelection().anchorNode

It returns a "Restricted { }" object instead of the actual input element, this differs from any other text input elements that correctly report the input element. This is an issue when testing the parents, because `.parentNode` will yield 'Error: Permission denied to access property "parentNode"'.


Actual results:

> getSelection().anchorNode
< Restricted { }


Expected results:

> getSelection().anchorNode
< (should show the input element)

Comment 1

[Jens Hausdorf :jens1o [ni? me]]

Can reproduce both in Nightly(64) and in the release channel(62).

Comment 2

[Daniel_A[:daschilean] [Please contact - [e-mail]]]

User Agent:  Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:64.0) Gecko/20100101 Firefox/64.0
Build ID:20181003100127    
I manage to reproduce this on Windows 10 x64 with the latest Firefox Nightly 64.0a1 (2018-10-03) (64-bit).

Comment 3

[Calixte Denizet (:calixte)]

The priority flag is not set for this bug and there is no activity for 2 weeks.
:overholt, could you have a look please ?

Comment 4

[Andrew Overholt [:overholt]]

Hsin-Yi, can you check into the age of this issue and if we have dupe(s) of it?

Comment 5

[Hsin-Yi Tsai (she/her) (REO Fx 129) [:hsinyi]]

I'll try to get back here soon.

Comment 6

[Bartosz Dziewoński]

This issue affects Wikipedia's VisualEditor: https://phabricator.wikimedia.org/T209646

Comment 7

[Hsin-Yi Tsai (she/her) (REO Fx 129) [:hsinyi]]

The behaviour of returning a restricted object was showing up in 61. Before 61, the behaviour was somewhat different, it returned null or undefined. I ran mozregression and got this Bug 1447189 that doesn't look relevant here tho...

Anyway, I think this should be P2 given comment 6.

Edgar, do you think you could help with this? Thank you.

Comment 8

[Edgar Chen [:edgar]]

Attachment: test_bug1495482.html

(In reply to Alexander Ebert from comment #0)
> Expected results:
> 
> > getSelection().anchorNode
> < (should show the input element)

Both Goole Chrome and Safari returns the body element, not the input element.

In Firefox, getSelection().anchorNode returns body element with other types of input element (datetime, text ..), but console shows "Error: Permission denied .." with number type. And I got the same behavior on Firefox 51.

Comment 9

[Edgar Chen [:edgar]]

We create an anonymous tree for our input element (number type) that is structured as https://searchfox.org/mozilla-central/rev/876022232b15425bb9efde189caf747823b39567/layout/forms/nsNumberControlFrame.cpp#349-360. getSelection().anchorNode returns the element inside the anonymous tree, which is not visible on the content scope.

Comment 10

[Bartosz Dziewoński]

Attachment: test_bug1495482_b.html

(In reply to Edgar Chen [:edgar] from comment #8)
> (In reply to Alexander Ebert from comment #0)
> > Expected results:
> > 
> > > getSelection().anchorNode
> > < (should show the input element)
> 
> Both Goole Chrome and Safari returns the body element, not the input element.
> 
> In Firefox, getSelection().anchorNode returns body element with other types
> of input element (datetime, text ..), but console shows "Error: Permission
> denied .." with number type. And I got the same behavior on Firefox 51.

In Firefox, when the focussed node is an <input type=text>, getSelection().anchorNode can be either the node itself, or its parent node, apparently depending on how it got focussed?

Attached is a test case that demonstrates the node itself being the Selection anchorNode. (Click the input boxes to focus them and note the output below.)

This might be the expected behavior or a separate bug, I don't know.

Comment 11

[Emilio Cobos Álvarez (:emilio)]

Bug 981248 tracks removing the silly anonymous input, fwiw.

Comment 12

[Edgar Chen [:edgar]]

Not actively working on this.

Comment 13

[Edgar Chen [:edgar]]

Hi Kagami, is this something that would also be fixed by bug 1669996?

Comment 14

[Kagami Rosylight [:saschanaz] (they/them)]

I can't repro this on Nightly, it seems this specific one already has been fixed probably by Emilio in Bug 981248.

Comment 15

[Edgar Chen [:edgar]]

(In reply to Kagami :saschanaz from comment #14)

I can't repro this on Nightly, it seems this specific one already has been fixed probably by Emilio in Bug 981248.

Thanks!