Closed
Bug 824080
Opened 12 years ago
Closed 11 years ago
selection color outside contenteditable elements becomes gray after a contenteditable element loses focus
Categories
(Core :: DOM: Selection, defect)
Core
DOM: Selection
Tracking
()
RESOLVED
FIXED
mozilla24
People
(Reporter: me, Assigned: masayuki)
References
(Blocks 1 open bug)
Details
(Keywords: testcase)
Attachments
(2 files)
1.18 KB,
text/html
|
Details | |
16.35 KB,
patch
|
ehsan.akhgari
:
review+
|
Details | Diff | Splinter Review |
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20100101 Firefox/17.0 Build ID: 20121128204232 Steps to reproduce: I created a div-element with attribute contenteditable set to "true". Actual results: When selecting (focusing) the contenteditable div, the selection color of the rest of the page turns to gray. Only after the page's focus has been entirely lost, for example by switching windows or reloading the page, it will return to the original color. Expected results: The selection color should have remained as it was instead of changing to gray.
Bug is reproducible on Linux x86_64 with another page than the test case. I'm using Firefox 17.
Updated•12 years ago
|
Attachment #694952 -
Attachment mime type: text/plain → text/html
Comment 2•12 years ago
|
||
confirming with Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20100101 Firefox/20.0 SeaMonkey/2.17a1 and Firefox 10ESR
Blocks: 176170
Status: UNCONFIRMED → NEW
Component: Untriaged → Style System (CSS)
Ever confirmed: true
Product: Firefox → Core
Updated•12 years ago
|
Component: Style System (CSS) → Selection
Assignee | ||
Updated•11 years ago
|
Assignee: nobody → masayuki
Status: NEW → ASSIGNED
OS: Windows 7 → All
Hardware: x86_64 → All
Version: 17 Branch → Trunk
Assignee | ||
Updated•11 years ago
|
Summary: contenteditable selectioncolor → selection color outside contenteditable elements becomes gray after a contenteditable element loses focus
Assignee | ||
Comment 3•11 years ago
|
||
If an editor uses selection controller of a presShell, that means the editor doesn't have independent selection. In such case, the editor must be an HTML editor. This bug is caused by HTML editor setting selection controller's state which is shared with the presShell at blur event handler. Thus, when HTML editor loses focus, the blur handler shouldn't mark the selection controller's state as inactive if the document still has focus. So, if the document has focus, it should mark the selection controller's state as normal. Otherwise, i.e., the document doesn't have focus, it should mark the selection controller's state as inactive.
Attachment #751099 -
Flags: review?(ehsan)
Assignee | ||
Comment 4•11 years ago
|
||
https://tbpl.mozilla.org/?tree=Try&usebuildbot=1&rev=3308151e4e55
Comment 5•11 years ago
|
||
Comment on attachment 751099 [details] [diff] [review] Patch Review of attachment 751099 [details] [diff] [review]: ----------------------------------------------------------------- Nice! ::: editor/libeditor/base/nsEditor.cpp @@ +4983,5 @@ > + } > + > + selCon->SetCaretEnabled(false); > + > + if (!HasIndependentSelection()) { Please add a comment here explaining what these branches do each. ::: editor/libeditor/base/nsEditor.h @@ +741,5 @@ > } > > + bool HasIndependentSelection() const > + { > + return (mSelConWeak != nullptr); Nit: !!mSelConWeak.
Attachment #751099 -
Flags: review?(ehsan) → review+
Assignee | ||
Comment 6•11 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/8a53b2daa50e
Comment 7•11 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/8a53b2daa50e
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla24
You need to log in
before you can comment on or make changes to this bug.
Description
•