Changes between Initial Version and Version 1 of Ticket #11145, comment 10


Ignore:
Timestamp:
Feb 23, 2015, 1:44:29 PM (8 years ago)
Author:
spjonez
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #11145, comment 10

    initial v1  
    11It is the same issue, 101444 fixed it by blocking the event but the current code uses range/selection save/restore code. I'm guessing these changes were needed for keypress to select. It does have the side effect of making the selection flicker when accessing the menu where the event prevent did not.
    22
    3 IMO keypress to select while inside a contenteditable isn't a big deal if your selection is lost. Not many users would do that in a rich editor use case. Maintaining the selection is necessary to apply commands to a range inside a contendeditable div. To resolve this ticket at the expense of keypress to select while inside a contenteditable only the focus call has to changed to only fire in IE. The focus call doesn't seem to effect FF/Chrome so it could also be changed to be ignored by Safari and called by all the rest.
     3IMO keypress to select an option while inside a contenteditable isn't a big deal if your selection is lost. Not many users would do that in a rich editor use case. Maintaining the selection when clicking the menu is necessary to apply commands to a range inside a contendeditable div. To resolve this ticket at the expense of keypress to select while inside a contenteditable only the focus call has to changed to only fire in IE. The focus call doesn't seem to effect FF/Chrome so it could also be changed to be ignored by Safari and called by all the rest.
    44
    55I doubt you can use feature detection as this is obviously a bug/nuance in Safari since all the other browsers respond differently. Do you have a policy on how situations such as this are resolved? I'm willing to take a stab at a patch but I don't want to code anything without knowing what your expectations are.