Last Comment Bug 716229 - Plain text in WWW pages now appears to be double-spaced? (line height is double, too tall, newlines, blockquote, pre)
: Plain text in WWW pages now appears to be double-spaced? (line height is dou...
Status: VERIFIED FIXED
[qa!]
: regression
Product: Core
Classification: Components
Component: Layout: Text (show other bugs)
: Trunk
: x86 Linux
: -- normal (vote)
: mozilla12
Assigned To: Jonathan Kew (:jfkthame)
:
Mentors:
: 716795 716858 716910 717852 (view as bug list)
Depends on:
Blocks: 703100
  Show dependency treegraph
 
Reported: 2012-01-07 06:29 PST by M ODonnell
Modified: 2012-03-30 08:23 PDT (History)
19 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
+
verified


Attachments
Screenshot, comparison between Nightly12.0a1 and Aurora11.0a2 (90.68 KB, image/png)
2012-01-07 11:55 PST, Alice0775 White
no flags Details
sample case (347 bytes, text/html)
2012-01-07 23:18 PST, chado
no flags Details
Screenshot of the bug with fontinfo box (68.86 KB, image/png)
2012-01-09 12:13 PST, Alexander L. Slovesnik
no flags Details
patch, don't switch fonts for non-printing control chars (3.91 KB, patch)
2012-01-10 04:33 PST, Jonathan Kew (:jfkthame)
roc: review+
Details | Diff | Review
patch 2, initialize font matching with the font-group's primary font (1019 bytes, patch)
2012-01-14 06:52 PST, Jonathan Kew (:jfkthame)
roc: review+
Details | Diff | Review

Description M ODonnell 2012-01-07 06:29:27 PST
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 2012-01-07 11:47:12 PST
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 2012-01-07 11:55:00 PST
Created attachment 586719 [details]
Screenshot, comparison between Nightly12.0a1 and Aurora11.0a2
Comment 3 chado 2012-01-07 23:18:43 PST
Created attachment 586761 [details]
sample case
Comment 4 chado 2012-01-07 23:20:19 PST
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 2012-01-08 09:11:56 PST
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) 2012-01-09 12:00:36 PST
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 2012-01-09 12:13:46 PST
Created attachment 587072 [details]
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 2012-01-09 12:20:03 PST
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 2012-01-09 12:21:20 PST
(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] 2012-01-09 13:16:27 PST
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) 2012-01-09 15:04:09 PST
(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 2012-01-09 16:21:02 PST
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) (Exited; email my personal email if necessary) 2012-01-09 17:11:33 PST
That does seem undesirable.
Comment 14 Daniel Holbert [:dholbert] 2012-01-09 21:26:58 PST
*** Bug 716795 has been marked as a duplicate of this bug. ***
Comment 15 Daniel Holbert [:dholbert] 2012-01-09 21:31:28 PST
(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) 2012-01-10 02:33:06 PST
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) 2012-01-10 04:33:23 PST
Created attachment 587275 [details] [diff] [review]
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 18 Jonathan Kew (:jfkthame) 2012-01-10 06:07:18 PST
*** Bug 716858 has been marked as a duplicate of this bug. ***
Comment 19 Jonathan Kew (:jfkthame) 2012-01-10 08:48:06 PST
*** Bug 716910 has been marked as a duplicate of this bug. ***
Comment 21 Ed Morley [:emorley] 2012-01-10 18:47:49 PST
https://hg.mozilla.org/mozilla-central/rev/9c2ca2a79d79
Comment 22 Jonathan Kew (:jfkthame) 2012-01-13 01:31:03 PST
*** Bug 717852 has been marked as a duplicate of this bug. ***
Comment 23 Chris AtLee [:catlee] 2012-01-13 07:24:59 PST
I'm seeing this again, although intermittently now, on the 2012-01-12 build.
Comment 24 :Ehsan Akhgari (busy, don't ask for review please) 2012-01-13 09:23:58 PST
*** Bug 717852 has been marked as a duplicate of this bug. ***
Comment 25 Jonathan Kew (:jfkthame) 2012-01-14 06:52:22 PST
Created attachment 588632 [details] [diff] [review]
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/jkew@mozilla.com-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) 2012-01-14 12:09:10 PST
(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/jkew@mozilla.com-
> 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) 2012-01-15 00:46:59 PST
Pushed patch 2 to inbound:
https://hg.mozilla.org/integration/mozilla-inbound/rev/1b67951de0a2
Comment 28 Jonathan Kew (:jfkthame) 2012-01-16 04:34:01 PST
https://hg.mozilla.org/mozilla-central/rev/1b67951de0a2
Comment 29 Alex Keybl [:akeybl] 2012-02-06 16:27:29 PST
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) 2012-02-06 16:52:47 PST
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] 2012-03-30 08:23:24 PDT
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.

Note You need to log in before you can comment on or make changes to this bug.