716229 - Plain text in WWW pages now appears to be double-spaced? (line height is double, too tall, newlines, blockquote, pre)

Status: VERIFIED FIXED

(Core :: Layout: Text and Fonts, defect)

Description

[M ODonnell]

User Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0a1) Gecko/20120107 Firefox/12.0a1
Build ID: 20120107031040

Steps to reproduce:

Allowed my version of "nightly" to update itself to 12.0a1 (2012-01-07) and now plain text in WWW pages now appears to be double-spaced?


Actual results:

Blank lines appear between each text line.


Expected results:

No blank lines should appear.

Comment 1

[Alice0775 White]

Confirmed on Debian  6.0.3 GNOME 2.30.2.
http://hg.mozilla.org/mozilla-central/rev/5a446202be5f
Mozilla/5.0 (X11; Linux i686; rv:12.0a1) Gecko/20120107 Firefox/12.0a1 ID:20120107031040

Regression window(m-c)
Works:
http://hg.mozilla.org/mozilla-central/rev/c7e27452a143
Mozilla/5.0 (X11; Linux i686; rv:12.0a1) Gecko/20120106 Firefox/12.0a1 ID:20120106031054
Fails:
http://hg.mozilla.org/mozilla-central/rev/fcc32e70c95f
Mozilla/5.0 (X11; Linux i686; rv:12.0a1) Gecko/20120106 Firefox/12.0a1 ID:20120106042423
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c7e27452a143&tochange=fcc32e70c95f


Regression window(m-i)
Works:
http://hg.mozilla.org/integration/mozilla-inbound/rev/511078d51f71
Mozilla/5.0 (X11; Linux i686; rv:12.0a1) Gecko/20120105 Firefox/12.0a1 ID:20120105035122
Fails:
http://hg.mozilla.org/integration/mozilla-inbound/rev/c0b62edd2917
Mozilla/5.0 (X11; Linux i686; rv:12.0a1) Gecko/20120105 Firefox/12.0a1 ID:20120105041225
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=511078d51f71&tochange=c0b62edd2917

Suspected: bug 703100

Comment 2

[Alice0775 White]

Attachment: Screenshot, comparison between Nightly12.0a1 and Aurora11.0a2

Comment 3

[chado]

Attachment: sample case

Comment 4

[chado]

Line breaking inside PRE (including plain text) or TEXTAREA looks
taking line height in double.  Tried selection or F7.

I'm seeing this on Debian 6.0.3 but not on Ubuntu 11.10, Fedora 16, 
LinuxMint 12 nor VineLinux 6.

  Debian 6.0.3  GNOME 2.30.2
  Ubuntu 11.10  GNOME 3.2.1
  Fedora 16  GNOME 3.2.1
  LinuxMint 12  GNOME 3.2.1
  VineLinux 6  GNOME 2.32.1

Comment 5

[Alice0775 White]

FYI, In local build, First bad changeset;
561d06710107	Jonathan Kew — bug 703100 - pt 2.4.1 - make gfxPangoFontGroup font-matching behavior more similar to generic gfxFontGroup version. r=roc

Comment 6

[Jonathan Kew [:jfkthame]]

What font(s) are being used to render the text when you see this problem? Please use "Show Fonts in Selection" from the fontinfo add-on[1] to verify the fonts being used both for the visible text and for the spaces.

[1] https://addons.mozilla.org/en-US/firefox/addon/fontinfo/

Comment 7

[Alexander L. Slovesnik]

Attachment: Screenshot of the bug with fontinfo box

(In reply to Jonathan Kew (:jfkthame) from comment #6)
> What font(s) are being used to render the text when you see this problem?
> Please use "Show Fonts in Selection" from the fontinfo add-on[1] to verify
> the fonts being used both for the visible text and for the spaces.
> 
> [1] https://addons.mozilla.org/en-US/firefox/addon/fontinfo/
2 fonts: DejaVu Sans Mono and wasy10

Comment 8

[Alexander L. Slovesnik]

I've removed ttf-lyx package (http://packages.ubuntu.com/en/maverick/ttf-lyx), that contains wasy10, and restarted browser. I'm no longer see this bug.

Comment 9

[Alice0775 White]

(In reply to Jonathan Kew (:jfkthame) from comment #6)
> What font(s) are being used to render the text when you see this problem?
> Please use "Show Fonts in Selection" from the fontinfo add-on[1] to verify
> the fonts being used both for the visible text and for the spaces.
> 
> [1] https://addons.mozilla.org/en-US/firefox/addon/fontinfo/

 for the visible text:
Bitstream Vera Sans Mono (default on newly installed Debian 6.0.3)
However ,This happens on any font (Century Schoolbook L Roman, Sazanami Mincho Regular, IPAGothic, ...).

for the spaces:  cannot select.

Comment 10

[[:Aleksej]]

I see the same thing as Alexander (on Debian testing), except that the first font is Droid Sans Mono; the ttf-lyx package is http://packages.debian.org/wheezy/ttf-lyx

Comment 11

[Jonathan Kew [:jfkthame]]

(In reply to Alice0775 White from comment #9)

>  for the visible text:
> Bitstream Vera Sans Mono (default on newly installed Debian 6.0.3)
> However ,This happens on any font (Century Schoolbook L Roman, Sazanami
> Mincho Regular, IPAGothic, ...).
> 
> for the spaces:  cannot select.

If you select a range of several words (so extending across the intervening spaces), does Show Fonts in Selection report more than any extra font (which would presumably be the font used for the spaces)?

Comment 12

[M ODonnell]

As suggested, I removed the ttf-lyx package from my system and text lines no longer appear double-spaced.

I also installed that fontinfo add-on and even though I'm no longer seeing the problem I do see two fonts reported when I ask it about a selection that includes a newline.  Example:

  DejaVu Sans Mono
  Terminus Regular

...while when I ask it about a selection that includes only letters and spaces I see only one font reported:

  DejaVu Sans Mono

Since I'm just a civilian I'm not sure if that's expected behavior.

Comment 13

[Robert O'Callahan (:roc) (email my personal email if necessary)]

That does seem undesirable.

Comment 15

[Daniel Holbert [:dholbert]]

(In reply to M ODonnell from comment #12)
> As suggested, I removed the ttf-lyx package from my system and text lines no
> longer appear double-spaced.

Same here.  (More specifically -- after uninstalling the package, I had to reload any tabs that were affected by this bug -- after the reload, they were unaffected.)

This is likely to affect people who've installed the word processor "Abiword" - in Ubuntu 11.04, the "abiword" package recommends "abiword-plugin-mathview" which depends on ttf-lyx

Comment 16

[Jonathan Kew [:jfkthame]]

The problem is that many fonts don't include the newline character (as it's not supposed to be drawn as a character at all), but in the case of preformatted text, newline may be present in the text run when we perform font matching. (The same would apply to the tab character, too.) This means that font fallback may kick in and apply a different font to the newline (or tab) than the one being used for the "real" text, and if this font - like wasy10 - has substantially different metrics, it will disrupt line spacing.

I'm testing a patch that should fix this by making the font-matching process assign non-printing control characters to the same font as their surrounding text, even if the font doesn't explicitly "support" them.

Comment 17

[Jonathan Kew [:jfkthame]]

Attachment: patch, don't switch fonts for non-printing control chars

This restores the significant part of the older gfxPangoFontGroup matching behavior prior to bug 703100: control characters will be treated as coming from the same font as the preceding text, regardless of whether they're actually present in it.

The same change is made in gfxFontGroup::FindFontForChar, because even though this was only reported for Linux, the problem could in principle arise on other platforms as well, depending on the particular repertoire of fonts installed locally.

I think we can create a reftest for this, though it may require building custom fonts to ensure we have a setup that exhibits the problem - will look into this further.

Comment 20

[Jonathan Kew [:jfkthame]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/9c2ca2a79d79

Comment 21

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/9c2ca2a79d79

Comment 23

[Chris AtLee [:catlee]]

I'm seeing this again, although intermittently now, on the 2012-01-12 build.

Comment 25

[Jonathan Kew [:jfkthame]]

Attachment: patch 2, initialize font matching with the font-group's primary font

The remaining issue arises when the text run passed to ComputeRanges *starts* with a non-printing control character such as tab or newline which isn't present in the "real" font we're going to use, and fallback picks something like wasy10 with weird metrics.

To fix this, we can simply initialize the "previous font" to the font-group's primary face, instead of null, so that initial control characters will be assigned to this font instead of relying on (somewhat unpredictable) fallback behavior.

Tryserver build with this patch is at https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-a681b91239a9/ if people would like to check that it resolves the issue (which is dependent on your particular collection of installed fonts).

Comment 26

[Matt Brubeck (:mbrubeck)]

(In reply to Jonathan Kew (:jfkthame) from comment #25)
> Tryserver build with this patch is at
> https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-
> a681b91239a9/ if people would like to check that it resolves the issue
> (which is dependent on your particular collection of installed fonts).

This build fixes the problem on my Linux system.

Comment 27

[Jonathan Kew [:jfkthame]]

Pushed patch 2 to inbound:
https://hg.mozilla.org/integration/mozilla-inbound/rev/1b67951de0a2

Comment 28

[Jonathan Kew [:jfkthame]]

https://hg.mozilla.org/mozilla-central/rev/1b67951de0a2

Comment 29

[Alex Keybl [:akeybl]]

This appears to be a regression in FF12. Are we comfortable with uplifting the patch on m-c to Aurora 12?

Comment 30

[Matt Brubeck (:mbrubeck)]

Both patches landed while mozilla-central was still Firefox 12, so they are already in Aurora for Firefox 12:

https://hg.mozilla.org/releases/mozilla-aurora/rev/9c2ca2a79d79
https://hg.mozilla.org/releases/mozilla-aurora/rev/1b67951de0a2

Comment 31

[Virgil Dicu [:virgil] [QA]]

Mozilla/5.0 (X11; Linux i686; rv:12.0a1) Gecko/20120109 Firefox/12.0a1
Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20100101 Firefox/12.0

Verified using sample test case on Ubuntu 11.10 with ttf-lyx fonts installed. 

Could previously reproduce the issue (with Gecko/20120109). No longer seeing this with f12 beta 3.