Closed Bug 642823 Opened 10 years ago Closed 10 years ago

Make nsISelection::Modify consistent on word granularity selection modifications

Categories

(Core :: DOM: Selection, defect)

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla5

People

(Reporter: ehsan, Assigned: ehsan)

References

Details

(Keywords: dev-doc-complete)

Attachments

(2 files, 1 obsolete file)

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.
Blocks: 642704
Attached 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+
Blocks: 496275
(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)
With the actual contents of the patch!
Attachment #520548 - Attachment is obsolete: true
Attachment #520548 - Flags: review?(roc)
Attachment #520549 - Flags: review?(roc)
Depends on: post2.0
Whiteboard: [post2.0]
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.
http://hg.mozilla.org/mozilla-central/rev/d09549b1b664
http://hg.mozilla.org/mozilla-central/rev/57770167ce80
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
No longer depends on: post2.0
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: [post2.0]
Target Milestone: --- → mozilla2.2
(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.