Make nsISelection::Modify consistent on word granularity selection modifications

RESOLVED FIXED in mozilla5

Status

()

defect
RESOLVED FIXED
8 years ago
8 years ago

People

(Reporter: Ehsan, Assigned: Ehsan)

Tracking

({dev-doc-complete})

Trunk
mozilla5
x86
macOS
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 1 obsolete attachment)

Assignee

Description

8 years ago
Currently, the behavior of nsISelection::Modify depends on the layout.word_select.eat_space_to_next_word pref.  I don't think that makes a lot of sense, because the results of calling the API from the web page would depend on the OS.

I'm planning to change this behavior to make it more consistent.  I think assuming eat_space_to_next_word being false is the saner of the two approaches.
Assignee

Updated

8 years ago
Blocks: 642704
Assignee

Comment 1

8 years ago
Posted patch Patch (v1)Splinter Review
The webkit implementation also does this.
Assignee: nobody → ehsan
Status: NEW → ASSIGNED
Attachment #520250 - Flags: review?(roc)
Comment on attachment 520250 [details] [diff] [review]
Patch (v1)

I guess this would be easy to test?
Attachment #520250 - Flags: review?(roc) → review+
Assignee

Updated

8 years ago
Blocks: 496275
Assignee

Comment 3

8 years ago
(In reply to comment #2)
> Comment on attachment 520250 [details] [diff] [review]
> Patch (v1)
> 
> I guess this would be easy to test?

Yes.  The richtext2 suite actually tests this, but I also found the test for bug 496275 which explicitly tested for the Windows specific behavior.  This patch removes that check, which makes us effectively test the new behavior of selection.modify across all platforms.
Attachment #520548 - Flags: review?(roc)
Assignee

Comment 4

8 years ago
With the actual contents of the patch!
Attachment #520548 - Attachment is obsolete: true
Attachment #520548 - Flags: review?(roc)
Attachment #520549 - Flags: review?(roc)
Assignee

Updated

8 years ago
Depends on: post2.0
Whiteboard: [post2.0]

Comment 5

8 years ago
I guess this is a question of use-cases. The original intent of this API was explicitly to expose the platform-specific selection behavior so that web apps could appropriately mimic it. Also, isn't this just choosing one platform's behavior other the other?

Maybe it's worth bringing this up on whatwg@? If we're going to deviate from platform-specific behavior, we should probably pick something consistent with the rest of the web platform as per http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-January/030120.html.
Assignee

Comment 6

8 years ago
http://hg.mozilla.org/mozilla-central/rev/d09549b1b664
http://hg.mozilla.org/mozilla-central/rev/57770167ce80
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
No longer depends on: post2.0
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: [post2.0]
Target Milestone: --- → mozilla2.2
Assignee

Comment 7

8 years ago
(In reply to comment #5)
> I guess this is a question of use-cases. The original intent of this API was
> explicitly to expose the platform-specific selection behavior so that web apps
> could appropriately mimic it. Also, isn't this just choosing one platform's
> behavior other the other?
> 
> Maybe it's worth bringing this up on whatwg@? If we're going to deviate from
> platform-specific behavior, we should probably pick something consistent with
> the rest of the web platform as per
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-January/030120.html.

I'll post about this to whatwg.  Currently our behavior matches that of Webkit, and if it is decided that this needs to be platform specific, we can revert this change.
This change has been noted here:

https://developer.mozilla.org/en/DOM/Selection/modify

Also mentioned on Firefox 5 for developers.

Documented as shipping in Firefox 5. Please advise if this is not correct.
You need to log in before you can comment on or make changes to this bug.