[Qt] Ensure zero-width space effectively accounts for a width of zero.
Created attachment 138344 [details] Patch
Committed r114899: <http://trac.webkit.org/changeset/114899>
Reopen, because it broke 62 tests on Qt5-WK1 and WK2 bots ... Could you check if it is regression or progression and then fix it soon?
Comment on attachment 138344 [details] Patch I skipped the failing tests to make the bot green and be able catch new regressions - http://trac.webkit.org/changeset/114905 Please unskip the tests with the proper fix. Just a question: Wouldn't be simpler to run layout tests before landing?
Committed new baselines manually in r114913: <http://trac.webkit.org/changeset/114913>
Reopen again, because two tests are still failing: - editing/selection/5354455-1.html - editing/selection/click-left-of-rtl-wrapping-text.html The first one is still fail on the bot: --- /home/webkitbuildbot/slaves/release32bit-qt5/buildslave/qt-linux-32-release-qt5/build/layout-test-results/editing/selection/5354455-1-expected.txt +++ /home/webkitbuildbot/slaves/release32bit-qt5/buildslave/qt-linux-32-release-qt5/build/layout-test-results/editing/selection/5354455-1-actual.txt @@ -1,6 +1,6 @@ This tests whether right clicking on a paragraph break in editable content selects it. The break should be selected on OS X, but not on Windows or Unix. To run it manually, right click on the paragraph break after the first paragraph below. -The following paragraph break should be selected on OS X. + Mac: Caret Win: Caret For the second one you committed wrong expected result: http://trac.webkit.org/browser/trunk/LayoutTests/platform/qt-5.0/editing/selection/click-left-of-rtl-wrapping-text-expected.txt?rev=114908 (diff: http://build.webkit.sed.hu/results/x86-32%20Linux%20Qt%20Release%20-%20Qt5-WebKit1/r114902%20%286441%29/editing/selection/click-left-of-rtl-wrapping-text-pretty-diff.html) It's hard to believe if it is the correct result. In my head FAIL instead of PASS words always mean regression. I'm going to skip these tests again to make bots happier a little bit.
I skipped them _again_ - http://trac.webkit.org/changeset/115010/trunk/LayoutTests/platform/qt-5.0/Skipped Please unskip them with the proper fix.
(In reply to comment #7) > I skipped them _again_ - http://trac.webkit.org/changeset/115010/trunk/LayoutTests/platform/qt-5.0/Skipped > > Please unskip them with the proper fix. Ossy, editing/selection/click-left-of-rtl-wrapping-text.html is passing locally for me with Qt5. Can you check and see if we can just unskip it please? I will have a look now at the other one. thanks!
editing/selection/5354455-1.html is not working because we need layoutTestController.setEditingBehavior (bug 42689).
(In reply to comment #8) > (In reply to comment #7) > > I skipped them _again_ - http://trac.webkit.org/changeset/115010/trunk/LayoutTests/platform/qt-5.0/Skipped > > > > Please unskip them with the proper fix. > > Ossy, editing/selection/click-left-of-rtl-wrapping-text.html is passing locally for me with Qt5. Can you check and see if we can just unskip it please? I will have a look now at the other one. Yes, it passes, because _WRONG_ expected file was committed with 3 big FAIL message. So it is still valid bug.
(In reply to comment #9) > editing/selection/5354455-1.html is not working because we need layoutTestController.setEditingBehavior (bug 42689). But it fails on Qt5-WK1, it is unrelated to WK2 missing feature you mentioned. And it passed before and fail now, so it is a regression.
editing/selection/click-left-of-rtl-wrapping-text.html passes now (I updated the expected file by r135382), but the other test still fails, because r114899 _broke_ it. I filed a new bug report to track this _regression_ - https://bugs.webkit.org/show_bug.cgi?id=102920
(In reply to comment #12) > editing/selection/click-left-of-rtl-wrapping-text.html passes now (I updated > the expected file by r135382), but the other test still fails, because r114899 > _broke_ it. I filed a new bug report to track this _regression_ - https://bugs.webkit.org/show_bug.cgi?id=102920 This was only intended as a workaround originally, but an attempt at fixing the root problem didn't turn out to be that popular. So we're stuck with that for now. I'll take another crack at it and maybe try a different approach once we're done with the WebKitWidget split.