Permission denied error thrown when accessing selection.anchorNode.nodeType next to CSS generated text

NEW
Unassigned

Status

()

Core
Selection
3 years ago
3 months ago

People

(Reporter: Piotrek Koszuliński, Unassigned)

Tracking

({testcase})

30 Branch
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

3 years ago
Created attachment 8452237 [details]
ff-permission-denied.html

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36

Steps to reproduce:

1. Open attached sample.
2. Focus editable element.
3. Press end to move caret after the CSS generated "[foo]" text.
4. Slowly press left arrow few times. Observe console.

This issue was reported on CKEditor's bug tracker: http://dev.ckeditor.com/ticket/12179


Actual results:

Permission denied error is logged:

Error: Permission denied to access property 'nodeType'


Expected results:

It's not entirely clear what should happen with CSS generated text in contenteditable. I think that there are 3 possible solutions:

1. Selection should never be anchored in CSS generated text node - it should behave as unselectable fragment.
2. CSS generated content should not work in contenteditable at all.
3. Error should not be thrown and node should be accessible. Though, I guess that CSS generated text node has no representation in real DOM.

Personally I would say that solution 1. makes most sense.
See also: bug 12460.
Status: UNCONFIRMED → NEW
Component: Untriaged → Selection
Ever confirmed: true
Keywords: testcase
OS: Mac OS X → All
Product: Firefox → Core
Hardware: x86 → All

Comment 2

3 months ago
This is definitely a liability -- doing something entirely reasonable like reading properties from a (non-null) `selection.anchorNode` will crash your program. We ran into this with ProseMirror as well (https://github.com/ProseMirror/prosemirror/issues/678).

Piotrek's third suggestion (return undefined instead of erroring when such a property is accessed) would, I believe, be a relatively easy fix and make this corner case much less problematic.
You need to log in before you can comment on or make changes to this bug.