Closed
Bug 442801
Opened 16 years ago
Closed 16 years ago
No caret or wrongly positioned caret within contenteditable=inherit element
Categories
(Core :: DOM: Editor, defect)
Core
DOM: Editor
Tracking
()
RESOLVED
FIXED
mozilla1.9.1b2
People
(Reporter: martijn.martijn, Assigned: arno)
References
Details
(Keywords: testcase)
Attachments
(2 files, 1 obsolete file)
333 bytes,
text/html
|
Details | |
3.54 KB,
patch
|
arno
:
review+
arno
:
superreview+
|
Details | Diff | Splinter Review |
See testcase, click somewhere in the text and start typing.
A lot of times, I just don't get a caret and when I get a caret, its position doesn't change when typing.
Assignee | ||
Comment 1•16 years ago
|
||
In you click, you don't get a caret *immediately* but if you wait a few seconds, caret will start blinking. Also, when typing something, caret is not *immediately* deplaced. But if wait blinking, caret will move to the right place.
It's because in inner div style "mUserModify" is set to read-only. So, when calling nsCaret::DrawAtPositionWithHint after text has been inserted, caret position will not be updated[1].
usermodify property is set to read-only on inner div in nsGenericHTMLElement::MapCommonAttributesInto because contenteditable attribute is neither empty, neither "true" [2], but according to spec[3] it should be set to read-write if attribute true or empty, read-only if attribute is false, and it should search for a parent with contenteditable attribute in other cases.
[1]: http://mxr.mozilla.org/mozilla/source/layout/base/nsCaret.cpp#607
[2]: http://mxr.mozilla.org/mozilla/source/content/html/content/src/nsGenericHTMLElement.cpp#1894
[3]: http://www.whatwg.org/specs/web-apps/current-work/#contenteditable
Assignee | ||
Comment 2•16 years ago
|
||
Assignee: nobody → arenevier
Attachment #341743 -
Flags: review?
Assignee | ||
Updated•16 years ago
|
Attachment #341743 -
Flags: review? → review?(peterv)
Updated•16 years ago
|
Attachment #341743 -
Flags: superreview+
Attachment #341743 -
Flags: review?(peterv)
Attachment #341743 -
Flags: review+
Comment 3•16 years ago
|
||
Comment on attachment 341743 [details] [diff] [review]
patch v1
>diff -r 184ad4f909cd content/html/content/src/nsGenericHTMLElement.cpp
>- }
>- else {
>- ui->mUserModify.SetIntValue(NS_STYLE_USER_MODIFY_READ_ONLY,
>- eCSSUnit_Enumerated);
>+ } else if (value->Equals(nsGkAtoms::_false, eIgnoreCase)) {
Keep the else on its own line.
Assignee | ||
Comment 4•16 years ago
|
||
same patch with "else" on its own line (addressing peterv comment)
Attachment #341743 -
Attachment is obsolete: true
Attachment #341911 -
Flags: superreview+
Attachment #341911 -
Flags: review+
Assignee | ||
Updated•16 years ago
|
Keywords: checkin-needed
Updated•16 years ago
|
Attachment #341911 -
Attachment description: patch v1.1 → patch v1.1
[Checkin: Comment 5]
Comment 5•16 years ago
|
||
Comment on attachment 341911 [details] [diff] [review]
patch v1.1
[Checkin: Comment 5]
http://hg.mozilla.org/mozilla-central/rev/fb32055b742a
Updated•16 years ago
|
Status: NEW → RESOLVED
Closed: 16 years ago
Flags: in-testsuite+
Keywords: checkin-needed
OS: Windows XP → All
Hardware: PC → All
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.1b2
You need to log in
before you can comment on or make changes to this bug.
Description
•