Closed
Bug 745555
Opened 12 years ago
Closed 12 years ago
line-breaking position is different between Firefox12-Nightly14.0a1 and Firefox11
Categories
(Core :: Layout: Text and Fonts, defect)
Tracking
()
RESOLVED
FIXED
mozilla14
People
(Reporter: alice0775, Assigned: jfkthame)
References
Details
(Keywords: regression, Whiteboard: [qa+])
Attachments
(4 files)
40.60 KB,
image/png
|
Details | |
3.98 KB,
patch
|
roc
:
review+
akeybl
:
approval-mozilla-aurora+
akeybl
:
approval-mozilla-beta-
|
Details | Diff | Splinter Review |
4.33 KB,
patch
|
roc
:
review+
|
Details | Diff | Splinter Review |
107.57 KB,
image/png
|
Details |
Build Identifier: http://hg.mozilla.org/mozilla-central/rev/0d871550085e Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120415 Firefox/14.0a1 ID:20120415030725 I encounter a problem when I test Bug 745454. line-breaking position is different between Firefox11 and Firefox12-Nightly14.0a1) Reproducible: Always Steps to reproduce: 1. Open attachment 615053 [details] Actual results: line-breaking position is different between Firefox12-Nightly14.0a1 and Firefox11 Expected results: line-breaking position should be same as Firefox11. Regression window(m-c) Cannot reproduce: http://hg.mozilla.org/mozilla-central/rev/8ae16e346bd0 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a1) Gecko/20120106 Firefox/12.0a1 ID:20120106031054 Can reproduce: http://hg.mozilla.org/mozilla-central/rev/fcc32e70c95f Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a1) Gecko/20120105 Firefox/12.0a1 ID:20120106042423 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=8ae16e346bd0&tochange=fcc32e70c95f Regression window(m-c) Cannot reproduce: http://hg.mozilla.org/integration/mozilla-inbound/rev/511078d51f71 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a1) Gecko/20120105 Firefox/12.0a1 ID:20120105035122 Can reproduce: http://hg.mozilla.org/integration/mozilla-inbound/rev/c0b62edd2917 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a1) Gecko/20120105 Firefox/12.0a1 ID:20120105041225 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=511078d51f71&tochange=c0b62edd2917 Triggered by: bug 703100
Reporter | ||
Comment 1•12 years ago
|
||
In my environment(Windows 7 Japanese edition), these font is MS PGothic . Graphics Adapter Description: ATI Radeon HD 4300/4500 Series Vendor ID: 0x1002 Device ID: 0x954f Adapter RAM: 512 Adapter Drivers: aticfx64 aticfx64 aticfx32 aticfx32 atiumd64 atidxx64 atiumdag atidxx32 atiumdva atiumd6a atitmm64 Driver Version: 8.951.0.0 Driver Date: 3-8-2012 Direct2D Enabled: true DirectWrite Enabled: true (6.1.7601.17776) ClearType Parameters: Gamma: 2200 Pixel Structure: RGB ClearType Level: 50 Enhanced Contrast: 200 WebGL Renderer: Google Inc. -- ANGLE (ATI Radeon HD 4300/4500 Series) -- OpenGL ES 2.0 (ANGLE 1.0.0.963) GPU Accelerated Windows: 1/1 Direct3D 10 AzureBackend: direct2d
Assignee | ||
Comment 2•12 years ago
|
||
Yes, I also found this - currently investigating. It's specifically triggered by bug 703100 part 3 (https://hg.mozilla.org/mozilla-central/rev/102dff1e0bb5).
Assignee | ||
Comment 3•12 years ago
|
||
Assignee: nobody → jfkthame
Attachment #615281 -
Flags: review?(roc)
Assignee | ||
Comment 4•12 years ago
|
||
Testcases for both the early-line-wrap problem (lost CHAR_IS_SPACE flag) and the handling of tab and newline in <pre> text (lost CHAR_IS_{TAB,NEWLINE} flags) when text-transform:uppercase is applied to es-zet.
Attachment #615282 -
Flags: review?(roc)
Assignee | ||
Updated•12 years ago
|
OS: Windows 7 → All
Hardware: x86 → All
Attachment #615281 -
Flags: review?(roc) → review+
Attachment #615282 -
Flags: review?(roc) → review+
Assignee | ||
Comment 5•12 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/19d1e35cff9a (patch) https://hg.mozilla.org/integration/mozilla-inbound/rev/6256b17dd252 (tests)
Target Milestone: --- → mozilla14
Assignee | ||
Comment 6•12 years ago
|
||
Testcase for FF12/FF13 demonstrating the effect in <pre>formatted text: data:text/html;charset=utf-8, <pre>%09fooß%09bar%09baz</pre> <pre style="text-transform:uppercase">%09fooß%09bar%09baz Note how the tabs in the uppercased <pre> element are lost.
Assignee | ||
Comment 7•12 years ago
|
||
Testcase demonstrating disruption to the right margin of text: data:text/html;charset=utf-8,<div style="text-transform:uppercase; border:1px solid red;text-align:right;width:4em">foo bar baß Notes re tracking-firefox-* nominations: this is a regression currently in FF12beta, caused by an oversight in bug 703100. AFAIK this would only affect text that contains ß (es-zet) *and* is styled with text-transform:uppercase (or capitalize, but ß shouldn't occur in word-initial position in any real text) or font-variant:small-caps. The effect on line-breaking is fairly minor, though it can disrupt the right edge of wrapped text when text-align:right (or justification, I expect) is in effect. However, the effect on <pre> is more drastic, as it can cause all tabs to be ignored, completely messing up the intended layout.
status-firefox12:
--- → affected
status-firefox13:
--- → affected
tracking-firefox12:
--- → ?
tracking-firefox13:
--- → ?
Assignee | ||
Comment 8•12 years ago
|
||
Comment on attachment 615281 [details] [diff] [review] patch, don't wipe out character-identification flags when setting new glyph information [Approval Request Comment] Regression caused by (bug #): 703100 User impact if declined: incorrect text layout (see examples above) when the ß character occurs in conjunction with uppercase transformation Testing completed (on m-c, etc.): patch landed on inbound with reftests Risk to taking this patch (and alternatives if risky): low risk - straightforward patch that just avoids improperly clearing character flags when case-transform is applied String changes made by this patch: none
Attachment #615281 -
Flags: approval-mozilla-beta?
Attachment #615281 -
Flags: approval-mozilla-aurora?
Comment 9•12 years ago
|
||
Comment on attachment 615281 [details] [diff] [review] patch, don't wipe out character-identification flags when setting new glyph information [Triage Comment] Based upon the minimal user impact and our proximity to FF12's release, we'll only take this on FF13 Aurora.
Attachment #615281 -
Flags: approval-mozilla-beta?
Attachment #615281 -
Flags: approval-mozilla-beta-
Attachment #615281 -
Flags: approval-mozilla-aurora?
Attachment #615281 -
Flags: approval-mozilla-aurora+
Updated•12 years ago
|
Assignee | ||
Comment 10•12 years ago
|
||
https://hg.mozilla.org/releases/mozilla-aurora/rev/01ae9ced59c6
Comment 11•12 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/19d1e35cff9a https://hg.mozilla.org/mozilla-central/rev/6256b17dd252
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Comment 12•12 years ago
|
||
Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20100101 Firefox/13.0 Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20100101 Firefox/13.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20100101 Firefox/13.0 Verified on Windows 7, Ubuntu 11.10 and Mac OS X 10 6 that the line-breaking position is the same on Firefox 11 and Firefox 13 beta 2. But the line-breaking position is different between Firefox 11 and Nightly 15a1. Is that intended?
Comment 13•12 years ago
|
||
I'm reopening this because it doesn't not work on the nightly. What's more, I don't see a difference in behavior between Fx12 and Fx3b7, which look ok. I'll leave those verified.
Updated•12 years ago
|
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Updated•12 years ago
|
Assignee | ||
Comment 14•12 years ago
|
||
The Fx15 behavior with this testcase is correct; Fx13 and earlier are wrong. The (incorrect) absence of line-breaks in the 4th and 5th <div>s of that testcase is exactly what bug 745454 was about, and it was fixed for Fx14.
Status: REOPENED → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → FIXED
Comment 15•12 years ago
|
||
Just doing a comparison here of the testcase in Firefox 11, each div (columns x rows): Firefox 11: 7x4, 5x4, 5x4, 1x27, 1x18, 3x6 Firefox 12: 8x4, 5x4, 5x4, 1x27, 1x18, 3x6 Firefox 13: 8x4, 5x4, 5x4, 1x27, 1x18, 3x6 Firefox 14: 8x4, 5x4, 5x4, 4x7, 3x6, 3x6 Firefox 15: 8x4, 5x4, 5x4, 4x7, 3x6, 3x6 If the purpose of this bug is to make all divs return to rendering like Firefox 11 then it's not clear to me that this is fixed. There are two points of confusion for QA: 1) No version of Firefox renders exactly the same as Firefox 11 2) Firefox 13 (fixed) renders the same as Firefox 12 (wontfix) Jonathan, apologies for the confusion, but I just want to make sure this is really fixed. If you say this is how it's supposed to render across all versions tested then I'll go along with that decision.
Assignee | ||
Comment 16•12 years ago
|
||
(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #15) > Just doing a comparison here of the testcase in Firefox 11, each div > (columns x rows): > > Firefox 11: 7x4, 5x4, 5x4, 1x27, 1x18, 3x6 > Firefox 12: 8x4, 5x4, 5x4, 1x27, 1x18, 3x6 > Firefox 13: 8x4, 5x4, 5x4, 1x27, 1x18, 3x6 > Firefox 14: 8x4, 5x4, 5x4, 4x7, 3x6, 3x6 > Firefox 15: 8x4, 5x4, 5x4, 4x7, 3x6, 3x6 > > If the purpose of this bug is to make all divs return to rendering like > Firefox 11 then it's not clear to me that this is fixed. The purpose of this bug can't be summed up that simply; Fx11 (and earlier versions) suffered from bug 745454, which is now fixed, resulting in different rendering. This bug is about a relatively small error whereby lines may wrap to a slightly shorter length than they should (because we don't allow the space character to effectively project beyond the right edge of the line), as shown in attachment 615176 [details]. This discrepancy is sensitive to the exact line width and font/size in use, so it may or may not show up in any given example. > > There are two points of confusion for QA: > 1) No version of Firefox renders exactly the same as Firefox 11 Right, because bug 745454 has been fixed in the meantime. > 2) Firefox 13 (fixed) renders the same as Firefox 12 (wontfix) It may render the same for that example, depending on your exact fonts; I believe Alice0775 was using a Japanese locale when attachment 615176 [details] was created, resulting in different default fonts from those we see on en-US systems. You should be able to see a difference between Fx12 and Fx13 with the testcases in layout/reftests/text/745555-*.html, which were specifically designed to exhibit the bug here.
Comment 17•12 years ago
|
||
Okay, thanks Jonathan. Leaving this marked verified for Firefox 13. Can you comment to the results posted earlier for Firefox 14 and 15? Is that expected?
Assignee | ||
Comment 18•12 years ago
|
||
Yes. The fact that the 4th and 5th <div>s failed to wrap on versions prior to Fx14 was bug 745454. That was fixed for 14, and the new behavior where those <div>s *do* wrap is the expected result.
You need to log in
before you can comment on or make changes to this bug.
Description
•