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)

12 Branch
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla14
Tracking Status
firefox12 - wontfix
firefox13 - verified

People

(Reporter: alice0775, Assigned: jfkthame)

References

Details

(Keywords: regression, Whiteboard: [qa+])

Attachments

(4 files)

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
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
Yes, I also found this - currently investigating. It's specifically triggered by bug 703100 part 3 (https://hg.mozilla.org/mozilla-central/rev/102dff1e0bb5).
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)
OS: Windows 7 → All
Hardware: x86 → All
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.
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.
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 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+
Whiteboard: [qa+]
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?
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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 ago12 years ago
Resolution: --- → FIXED
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.
(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.
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?
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.
Depends on: 780614
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: