It's not only for Chromium. Mac ports are also breaking. I'm suspecting http://trac.webkit.org/changeset/102875, but not sure.
According to the Chromium Builder, http://build.webkit.org/builders/Chromium%20Linux%20Release%20%28Tests%29 It starts between r102992 and r102996. But there is no doubtful change.
According to http://test-results.appspot.com/dashboards/flakiness_dashboard.html#group=%40ToT%20-%20webkit.org&tests=fast%2Fcss%2Fbidi-override-in-anonymous-block.html This is a regression from http://trac.webkit.org/changeset/103005/ Regression ranges: Chromium Win Release (Tests): http://trac.webkit.org/log/?verbose=on&rev=103009&stop_rev=103004 Chromium Linux Release (Tests): http://trac.webkit.org/log/?verbose=on&rev=103006&stop_rev=103001 SnowLeopard Intel Release (Tests): http://trac.webkit.org/log/?verbose=on&rev=103005&stop_rev=103002 And r103002-r103004 can't affect rendering like the way the test is failing.
Iām sure Adam will want to fix this, so assigning it to him to formalize that.
Any update on this regression?
Sorry, I didn't realize this was on my plate. I'll investigate on Tuesday.
*** Bug 75236 has been marked as a duplicate of this bug. ***
The new result is correct. This reflects the updated parsing of <rt> inside <rb> elements. I don't fully understand why the HTML5 spec changed in this regard, but from the discussion, it seems like this is the better parsing of ruby elements.
(In reply to comment #7) > The new result is correct. This reflects the updated parsing of <rt> inside <rb> elements. I don't fully understand why the HTML5 spec changed in this regard, but from the discussion, it seems like this is the better parsing of ruby elements. Okay. Let's rebaseline then.
Committed r103719: <http://trac.webkit.org/changeset/103719>
Committed r103721: <http://trac.webkit.org/changeset/103721>