2007-08-02-04 and 2007-08-03-04 linux trunk nightly builds. Many fonts and widgets do not display. Examples include almost the entirety of the CSS spec and much of bugzilla often, hovering a link or widget brings it to the front. Sometimes, dragging a window over affected text makes it visible. Sometimes, selecting text dislpays it, but select all almost never does. Backgrounds always display. This is almost certainly a regression from the cairo landing. I'm having trouble coming up with any sort of consistency in why this happens other than "it happens a lot". See the tescase in the URL field. If the first paragraph is serif and the second is sans, the first displays. If the first paragraph is sans and the second is serif, neither displays. However, I'd guess that I see a lot more sans-serif that displays properly on the web overall. The CSS spec and bugzilla aren't at all the only pages, indeed about half or more of the web seems to be affected. This makes firefox completely unusable, hence the blocker status. Note that, in true dogfood style, I tried typing this with an affected build, but the textarea wouldn't show the text at all.

Oh, this may be a dupe of 390622. (note that it's hard to tell when I can't read the bug report...

(In reply to comment #1) > Oh, this may be a dupe of 390622. (note that it's hard to tell when I can't > read the bug report... > The bug 390622 was fixed and confirmed (on Windows), but this one seems to be Linux only, and I see it too even with the latest build.

Something very similar happens to me. I can see almost no webpages. Also I can't see tabs. To narrow this down to the day when the new cairo landed I just looked at the tab bar to see whether the tabs are visible. The screenshot has two tabs open. I can ctrl-tab between them and click on where they're supposed to be to switch. I wonder if it's the same bug as this, except for the tabs the description of the problem is the same.

I also see this (even text in chrome is mostly not rendered for me). Not that there is a similar issue reported in the cairo bugtracker: https://bugs.freedesktop.org/show_bug.cgi?id=11068

> Not that there is a similar issue reported in the cairo bugtracker: I just ditched my ~/.fonts.conf, which had a <prefer> for Helvetica (bitmap), and now everything looks normal.

> I just ditched my ~/.fonts.conf, which had a <prefer> for Helvetica (bitmap), > and now everything looks normal. I also have a .fonts.conf that prefers bitmap fonts at specific sizes, so I may have to do the same as a workaround.

The adjustments to fonts.conf don't seem to cover everything. My prefs dialog started blanking out after a while (? :S). The top part of cnn.com and most of my webmail is missing widgets and text...

This looks pretty similar to bug 327879, but it only showed up recently for some people. It seems to be only a problem with bitmap fonts (which are the default for many western languages at least). The fonts show up at some sizes (which is not much help for dialogs).

This does seem like bug 327879, but I don't think the causes are the same. Besides that this only just appeared, I've observed the same text showing or not showing based only on where it is on the page, without changing the font or the size. Also, if you look at my screenshot (attachment 275249 [details]) up at the top in the flags section, you'll see them all displaying well until there's a hyphen in the text (that flag should be in-testsuite or in-litmus) and then it stops. Neither of those seems to be the case in the other bug, based on the bug's text and the screenshots there.

(In reply to comment #10) > if you look at my screenshot attachment 275249 [details] up at the top > in the flags section, you'll see them all displaying well until there's a > hyphen in the text (that flag should be in-testsuite or in-litmus) and then it > stops. I see the same here, thanks. Maybe there are two different things going on. I have cr->status = CAIRO_STATUS_NO_MEMORY in cairo_show_glyphs <- GlyphBuffer::Flush <- gfxFont::Draw causing at least one of the issues.

Bug 327879 makes bitmap fonts fail at some sizes (sometimes?). The cairo upgrade made cairo_scaled_font_create return a special nil font instead of NULL on failure. As we now cairo_set_scaled_font with this nil font it propagates the error in the font to the cairo_t so any further fonts are also not drawn. (So I'm thinking that previously only the hyphen, in a fallback bitmap font, may have been missing. Now all text later in the paint is missing.) We should really paint as much as possible if one font fails (this bug), but we should be painting something for all fonts too (bug 327879).

The hyphen is not missing in 2007-08-01, the last nightly build before cairo 1.5. However, I do note that it's not actually a hyphen, it's &#8209;, a non-breaking hyphen (U+2011), so it would make sense for it to need a fallback font.

(Something similar should be done for other platforms.)

The patch above makes the widgets and outline font text display. Bitmap fonts still often don't display, but that will be fixed in bug 327879. (In reply to comment #14) > The hyphen is not missing in 2007-08-01, the last nightly build before cairo > 1.5. However, I do note that it's not actually a hyphen, it's &#8209;, a > non-breaking hyphen (U+2011), so it would make sense for it to need a fallback > font. dolphinling: With the above patch, I don't see the non-breaking hyphens on my system. Maybe something different is happening on your system? If you are able to test this patch, can you let me know if it doesn't behave as expected, please?

Appears to have been fixed by the fix for bug 327978. Karl, is the patch in this bug still wanted? I'll leave this open in case it is, but feel free to mark this fixed otherwise. And thank you! :)

We should take this anyway for correctness purposes.

I'm running the latest hourly build and i'm still having this issue. Screenshot of Minefield with the issue: http://img503.imageshack.us/img503/3949/screenshotrevision3minemc3.png Screenshot of Firefox 2.0.0.6 without the issue: http://img265.imageshack.us/img265/9659/screenshotrevision3swifch2.png Running Debian Sid (Unstable) Linux, the version of Freetype is: 2.3.5 Log from running this command: env FC_DEBUG=1 /opt/firefox/firefox --no-remote http://www.revision3.com > log is at: https://bugzilla.mozilla.org/attachment.cgi?id=277627

cairo_scaled_font_create never returns NULL. cairo_win32_scaled_font_select_font checks status. cairo_win32_scaled_font_done_font doesn't do anything (at all).

(In reply to comment #20) > Created an attachment (id=277646) [details] > assert that cairo_scaled_font_create succeeds but recover if it doesn't > > cairo_scaled_font_create never returns NULL. > cairo_win32_scaled_font_select_font checks status. > cairo_win32_scaled_font_done_font doesn't do anything (at all). > @Karl - It seems that the directory for the patch isn't in any of my hourly builds...I take it in order to apply the patch i need to compile from source? Also, any idea when this new patch or the old patch will hit the builds?

(In reply to comment #21) > @Karl - It seems that the directory for the patch isn't in any of my hourly > builds...I take it in order to apply the patch i need to compile from source? Yes, but... > Also, any idea when this new patch or the old patch will hit the builds? When I work out how to use, http://tinderbox.mozilla.org/showbuilds.cgi?tree=MozillaTry they will be available here: https://build.mozilla.org/tryserver-builds/ with ktomlinson in the name, hopefully within hours.

I think to use that, you just have to follow the instructions here: http://wiki.mozilla.org/Build:TryServer

(In reply to comment #22) > hopefully within hours. This is going to take longer than I thought as the tryserver has "No space left on device".

@karl - Is this the Linux build with the fix: https://build.mozilla.org/tryserver-builds/52-ktomlinson@mozilla.com-firefox-try-linux.tar.bz2 ?

That build has a lot of problems. The "main" folder isn't chmodded correctly (has to be chmodded as root for ANYONE to be able to open it) and Firefox doesn't start (even after the chmodding), this is the commandline output i got: jd@thor:/opt/firefox$ ./firefox Cannot find mozilla runtime directory. Exiting. I've been extracting the other hourlies to that same directory and doing much of the same stuff and they've been starting fine.

OK, i finally got it to work. The problem is better, but it's still not fixed.

OK, i was in IRC and it was requested i clarify what's going on. What i mean when i say the problem is better is that text showed on the bottom of the Minefield start page (which it didn't before), but it didn't show anywhere else that it wasn't working before. Also, the Test Case in the URL field worked fine for me in the patched version, but as i said, out of 10 sites i went to, only 1 worked (google.com)

Thanks for testing JD. It sounds like this patch behaved as expected fixing some rendering but not all. If it is only text that you are missing (widgets are visible on bugzilla) then I think you are still seeing bug 327879. I'll reopen that.

More than text is missing (bug 327879 comment 36). JD, can you confirm that you are on an x86 (not x86_64 system), please? Does moving other windows over the missing elements make any difference? Would you be able to find the smallest page (least complicated) where you are seeing a problem, please?

I'm on x86, I've been testing it on 2 different x86 boxes with the same exact distro, software and versions of everything (the only difference between the 2 systems is they have different hardware). Moving a window over the missing elements does make some text appear, but only until focus goes back to Minefield (when i bring minefield to the front, the little bit of text that shows up goes away). twitter.com works, youtube.com works, cnn.com works, reddit.com works, distrowatch.com works, facebook.com works, myspace.com doesn't (has the issue), but when i mouseover content, it shows up, eztvefnet.org works, bt-chat.com does not work (has the issue)(this is prolly the least complex site having the issue that i can think of), yahoo.com doesn't work, digg.com does not work and revision3.com does not work. If you'd like to possibly get in touch with me faster than over these comments, feel free to IM me at: AIM: hackcomjd Jabber: jdhore@macjabber.de MSN: jdhorelick@gmail.com email/google talk: jdhore1@gmail.com

Does covering with another window make images or lines appear? What's probably most interesting is what doesn't appear when covering and uncovering with another window. The context menu (right-click) may be useful for making a small temporary window. There's another build here: https://build.mozilla.org/tryserver-builds/63-ktomlinson@mozilla.com-firefox-try-linux.tar.bz2 It's just the trunk with the patch for bug 327879 removed. (It doesn't include the patch here.) If this build works fine, that confirms that it is a regression from the 327879 patch and that it is a freetype interaction problem.

Covering the "invisible content" with the context menu does not make anything appear and with the new build, even covering it with a different window makes nothing appear. From that, i guess you could gather that this new build (63) didn't fix the problem.

OK, thank you. Forget the 63-ktomlinson build then. That proves that it is not a regression from the 327879 patch (only). I don't know what is going on. We need to narrow this down somehow. Either to a some feature (html element maybe?) that is causing the problem or to the change that caused the regression, or both. Are you able to go back to the 52-ktomlinson build then, please (that one has the patch from this bug). Which elements of the page do not appear (text/images/lines?) when you cover and uncover them with another window? (I'm not surprised that they disappear when focus shifts back to Minefield; using the context menu or Minefield menubar menus for a window may be convenient for avoiding that.) Is there any variation in what you see in the pages linked from here: http://www.chem.swin.edu.au/test/ Re a regression range: You said that your last working build was 20070820. Where exactly was that from? Is that still working for you? And your earliest build showing this issue was 2007082110. Where did this come from? So this is the set of changes from that period: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-08-20+00%3A00%3A00&maxdate=2007-08-21+10%3A00%3A00&cvsroot=%2Fcvsroot Nothing else looks particularly suspicious. I wondering whether bug 333126 may have triggered a build of something that should've been built earlier but had not. This depends on where exactly you got your builds, and how often they clobber before the build. (gtalk seems to need flash, and I don't have accounts on the other services. irc is easiest for me, if you are able to drop into #gfx on irc.mozilla.org in the next few hours - I don't know when you sleep).

Ignore the regression range in the previous comment. JD narrowed this down to a one day regression range consistent with the cairo 1.5.x landing in bug 383960. His tab bar is missing. This is a second tab (which is empty): http://img300.imageshack.us/img300/9992/screenshotminefieldrf6.png (http://www.chem.swin.edu.au/test/ rendered correctly.)

JD is also seeing bug 390786, so that may be related. Is anyone still seeing this bug after bug 327879 was fixed 2007-08-20 19:51:17 PDT, but not seeing bug 390786?

I am still seing this bug. I never saw bug 390786 on my machine.

FWIW, all the issues I was seeing (bitmap fonts not rendering at all since bug 383960 landed) have been fixed by the patch in bug 327879. I tested most of the sites mentioned in comment #31 and all of them WFM. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a8pre) Gecko/2007082304

Comment on attachment 278118 [details] bold fonts test works fine even with this bug

The patch should be landed, but doesn't resolve this bug.

If anyone who can reproduce has a debug build (preferably but not necessarily with the patch here), can they set a break point in _cairo_error and report the backtrace, please? Most (all?) binaries are distributed with unneeded symbols stripped, and so cannot break at _cairo_error. Anyone know of a build available for download with symbols? (BTW, I assigned myself this bug when I could reproduce. Now I can't reproduce, so feel free to take this bug if you can and want to work on it.)

Checked in: mozilla/gfx/thebes/src/gfxAtsuiFonts.cpp 1.61 mozilla/gfx/thebes/src/gfxOS2Fonts.cpp 1.14 mozilla/gfx/thebes/src/gfxPangoFonts.cpp 1.95 mozilla/gfx/thebes/src/gfxWindowsFonts.cpp 1.143

>If anyone who can reproduce has a debug build (preferably but not necessarily >with the patch here), can they set a break point in _cairo_error and report the >backtrace, please? Attached. It got into _cairo_error when I pressed ctrl+t to open a new tab. It's a debug build from today. The patch that just landed must have dealt with a different problem than I'm having, cause I see no difference.

Thanks, Andrew! So we are here: http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/gfx/cairo/cairo/src/cairo-xlib-surface.c&rev=1.28&mark=659-662#645 I guess we either shouldn't be here, or we need to handle some more formats.

This (second) issue seems to be triggered by background images. This url should display a grey bar with a gradient but nothing displays with this bug. data:text/html,<div%20style="background:url('chrome://browser/skin/tabbrowser/tabbrowser-tabs-bkgnd.png');height:30px"/> The same image displays fine (with the bug) in an img element: data:text/html,<img%20src="chrome://browser/skin/tabbrowser/tabbrowser-tabs-bkgnd.png"%20height="30px"%20width="300px"/>

There's been a bunch of work in the unsupported-formats area in current upstream cairo; I'll see about pulling that in the near future.

JD, can you attach the output from "xdpyinfo -ext RENDER", please?

The output of "xdpyinfo -ext RENDER" for ktomlinson

I'm resolving this bug as the originally reported issue has been fixed. The background image problem can be handled in bug 394465.