Explicitly set editingBehavior in some tests
Created attachment 195256 [details] Patch
Comment on attachment 195256 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=195256&action=review > LayoutTests/ChangeLog:66 > + * platform/chromium-win/editing/deleting/non-smart-delete-expected.txt: Updated. > + * platform/efl/editing/deleting/non-smart-delete-expected.txt: Updated. > + * platform/gtk/editing/deleting/non-smart-delete-expected.txt: Updated. > + * platform/qt/editing/deleting/non-smart-delete-expected.txt: Updated. Do these results still not match cross-paltforms ones?
(In reply to comment #2) > (From update of attachment 195256 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=195256&action=review > > > LayoutTests/ChangeLog:66 > > + * platform/chromium-win/editing/deleting/non-smart-delete-expected.txt: Updated. > > + * platform/efl/editing/deleting/non-smart-delete-expected.txt: Updated. > > + * platform/gtk/editing/deleting/non-smart-delete-expected.txt: Updated. > > + * platform/qt/editing/deleting/non-smart-delete-expected.txt: Updated. > > Do these results still not match cross-paltforms ones? Setting editingBehavior to Mac adds one emission of shouldChangeSelectedDOMRange that gets logged. This is consistent with the expectations file for Mac. The results otherwise are unchanged.
Comment on attachment 195256 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=195256&action=review > LayoutTests/ChangeLog:12 > + to use a non-Windows editingBehavior. As far as I know, the behavior on Linux matches that of Windows. > LayoutTests/editing/deleting/smart-delete-002.html:25 > + internals.settings.setEditingBehavior('mac'); Nit: tab character and a wrong indentation. > LayoutTests/editing/inserting/paragraph-outside-nested-divs.html:11 > + internals.settings.setEditingBehavior("mac"); Ditto. > LayoutTests/editing/pasteboard/drag-drop-modifies-page.html:10 > + internals.settings.setEditingBehavior("mac"); Ditto.
(In reply to comment #4) > (From update of attachment 195256 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=195256&action=review > > > LayoutTests/ChangeLog:12 > > + to use a non-Windows editingBehavior. > > As far as I know, the behavior on Linux matches that of Windows. > Thee are differences. Like what we're implementing in bug 110487. That applies only to Windows. Linux doesn't select spacing after the word.
(In reply to comment #5) > (In reply to comment #4) > > (From update of attachment 195256 [details] [details]) > > View in context: https://bugs.webkit.org/attachment.cgi?id=195256&action=review > > > > > LayoutTests/ChangeLog:12 > > > + to use a non-Windows editingBehavior. > > > > As far as I know, the behavior on Linux matches that of Windows. > > > > Thee are differences. Like what we're implementing in bug 110487. That applies only to Windows. Linux doesn't select spacing after the word. But that doesn't mean non-Windows behavior will always match in terms of word boundary movements so that phrase is imprecise to say the least. I'd much prefer explicitly saying use Mac behavior.
Created attachment 195366 [details] Patch for landing
Comment on attachment 195366 [details] Patch for landing Weird, webkit-patch didn't update the ChangeLog reviewer.
Created attachment 195367 [details] Patch for landing
Comment on attachment 195367 [details] Patch for landing Clearing flags on attachment: 195367 Committed r147036: <http://trac.webkit.org/changeset/147036>
All reviewed patches have been landed. Closing bug.