If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

selection color outside contenteditable elements becomes gray after a contenteditable element loses focus

RESOLVED FIXED in mozilla24

Status

()

Core
Selection
RESOLVED FIXED
5 years ago
4 years ago

People

(Reporter: PiJoKra, Assigned: masayuki)

Tracking

(Blocks: 1 bug, {testcase})

Trunk
mozilla24
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

5 years ago
Created attachment 694952 [details]
firefoxbug.htm

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.

Comment 1

5 years ago
Bug is reproducible on Linux x86_64 with another page than the test case. I'm using Firefox 17.
Attachment #694952 - Attachment mime type: text/plain → text/html
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
Component: Style System (CSS) → Selection

Updated

5 years ago
Keywords: testcase
Assignee: nobody → masayuki
Status: NEW → ASSIGNED
OS: Windows 7 → All
Hardware: x86_64 → All
Version: 17 Branch → Trunk
Summary: contenteditable selectioncolor → selection color outside contenteditable elements becomes gray after a contenteditable element loses focus
Created attachment 751099 [details] [diff] [review]
Patch

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)
https://tbpl.mozilla.org/?tree=Try&usebuildbot=1&rev=3308151e4e55
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+
https://hg.mozilla.org/integration/mozilla-inbound/rev/8a53b2daa50e
https://hg.mozilla.org/mozilla-central/rev/8a53b2daa50e
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla24
You need to log in before you can comment on or make changes to this bug.