633174 - http://hsivonen.iki.fi has no text displayed

Status: REOPENED

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

Description

[Anthony Ricaud (:rik)]

After bug 499292 has landed, the text is not displayed even after the timeout.

Comment 1

[Boris Zbarsky [:bzbarsky]]

This looks like a blocker to me....

Comment 2

[Anthony Ricaud (:rik)]

Looks like it is a problem with my local build. With a mozilla-central build[1], it's ok.

Also weird, other websites are displaying @font-face just fine with my local build.

[1] http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-macosx64/1297344448/

Comment 3

[Anthony Ricaud (:rik)]

I did a clean build after rm -rf objdir.

Same problem. My mozconfig only contains
mk_add_options MOZ_MAKE_FLAGS="-j5 -s"

I'm on OS X 10.6.6.

Comment 4

[John Daggett (:jtd)]

(In reply to comment #3)
Anthony, can you reproduce this with a m-c debug build (assuming your local build is a debug version)?  Also, did you try running with a a new profile?  Do you have any special settings in the profile where you see the problem?

Comment 5

[Anthony Ricaud (:rik)]

Sorry the bug does not contain every information since I discussed it with Jonathan on IRC.

(In reply to comment #4)
> (In reply to comment #3)
> Anthony, can you reproduce this with a m-c debug build (assuming your local
> build is a debug version)?
My local build is not a debug version. I'm currently building one. I've tried the build linked in comment #2, I don't know if this a debug build or not.

> Also, did you try running with a a new profile?
Yes, no change with a new profile.

> Do you have any special settings in the profile where you see the problem?
I tried changing gfx.downloadable_fonts.fallback_delay to 0 but it had no effect.

Comment 6

[Anthony Ricaud (:rik)]

With a debug build, when each font finish downloads, I get this

WARNING: Unable to test style tree integrity -- no content node: file /Users/rik24d/Documents/Mozilla/mozilla-central/layout/base/nsCSSFrameConstructor.cpp, line 8061

Comment 7

[Jonathan Kew [:jfkthame]]

(In reply to comment #6)
> With a debug build, when each font finish downloads, I get this
> 
> WARNING: Unable to test style tree integrity -- no content node: file
> /Users/rik24d/Documents/Mozilla/mozilla-central/layout/base/nsCSSFrameConstructor.cpp,
> line 8061

I think that's a pretty common message, and unrelated to the problem here. I see it frequently when things are working fine.

If you set the environment variable NSPR_LOG_MODULES to "userfonts:5,fontdownloader:5" before running the debug build, it should print some additional logging messages to show what's happening with the font downloads; that might be a step towards understanding this.

Comment 8

[Anthony Ricaud (:rik)]

Here is the output when loading with the NSPR_LOG_MODULES http://pastebin.mozilla.org/1048344

Comment 9

[Jonathan Kew [:jfkthame]]

Thanks for that. Note that I'm investigating a similar-looking issue in bug 633500; I don't quite understand your case yet (especially the difference between your local build and mozilla-central builds), but I think the root cause is related.

Comment 10

[Jonathan Kew [:jfkthame]]

I have just landed a patch for bug 633500, and I suspect this will also resolve the problem you've been seeing in your local build, though I have not been able to reproduce that exact issue for testing. Please re-try with a fresh build and let me know if the problem persists - thanks.

Comment 11

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

If this isn't fixed by bug 633500, I think we should back out bug 499292 for FF4.

Comment 12

[Anthony Ricaud (:rik)]

I'm sad to say that the text is still not displayed after bug 633500.

I've tried selecting the text before fallback is displayed. The pre-fallback and fallback text have the same size. The post-download non-displayed text has a smaller width, so it looks like the metrics of the downloaded font are "understood".

(In reply to comment #11)
> If this isn't fixed by bug 633500, I think we should back out bug 499292 for
> FF4.
I'm not sure that's necessary. I'm the only one to see that on my local builds. m-c builds and nightly builds are working just fine on the same machine. I may have a bad configuration for building, so unless someone else confirms that, why block. I have to add that I'm not fluent with makefiles, build options and all.

Comment 13

[Jonathan Kew [:jfkthame]]

(In reply to comment #12)
> I'm sad to say that the text is still not displayed after bug 633500.
> 
> I've tried selecting the text before fallback is displayed. The pre-fallback
> and fallback text have the same size. The post-download non-displayed text has
> a smaller width, so it looks like the metrics of the downloaded font are
> "understood".
> 
> (In reply to comment #11)
> > If this isn't fixed by bug 633500, I think we should back out bug 499292 for
> > FF4.
> I'm not sure that's necessary. I'm the only one to see that on my local builds.
> m-c builds and nightly builds are working just fine on the same machine. I may
> have a bad configuration for building, so unless someone else confirms that,
> why block. I have to add that I'm not fluent with makefiles, build options and
> all.

Could you possibly send me your build, please? (Or better, put it somewhere online that I can download.) Debug build preferred. I'm curious to see if your build exhibits the problem on my system, or if it's somehow unique to the combination of your build and your machine. (Do you have access to other machines where you could test?)

Comment 14

[Anthony Ricaud (:rik)]

Ok that is weird, it's now working. I copied the .app directory to my Desktop to put it online and just before doing so, I open it to check if it's launching. Boom, the fonts are now working. So I launched the original in the objdir directory, working also. With a new profile, working.

Between Saturday and today, I don't think I've done anything special to my system. So closing this.

Comment 15

[Jonathan Kew [:jfkthame]]

Glad it's working, though I'm still curious to understand exactly what happened. The only reasonable explanation I can think of at the moment is that when you made and tested an updated build with the fix from bug 633500, you had inadvertently left your older build running - probably with no windows open, so it was easy to overlook - and so "launching" the new build didn't really do so, it just activated the already-running one. Does that seem even remotely possible?

Comment 16

[Henri Sivonen (:hsivonen)]

(In reply to comment #15)
> The only reasonable explanation I can think of at the moment is that
> when you made and tested an updated build with the fix from bug 633500, you had
> inadvertently left your older build running - probably with no windows open, so
> it was easy to overlook - and so "launching" the new build didn't really do so,
> it just activated the already-running one.

Can that happen on Mac?

Comment 17

[Anthony Ricaud (:rik)]

OK, things are a bit clearer.

If I launch MinefieldDebug.app from the Finder, things work.
If I launch from the Terminal, things don't work.

Commands I used in the Terminal:
open MinefieldDebug.app
./MinefieldDebug.app/Contents/MacOS/firefox

I thought "open" was the equivalent of launching through the Finder, apparently not.

(In reply to comment #16)
> Can that happen on Mac?
Yes. Only a small number of apps close when you close last window.

Comment 18

[Jonathan Kew [:jfkthame]]

(In reply to comment #16)
> (In reply to comment #15)
> > The only reasonable explanation I can think of at the moment is that
> > when you made and tested an updated build with the fix from bug 633500, you had
> > inadvertently left your older build running - probably with no windows open, so
> > it was easy to overlook - and so "launching" the new build didn't really do so,
> > it just activated the already-running one.
> 
> Can that happen on Mac?

Yes, if you try to launch the new build from the Finder; that will automagically activate an already-running (potentially older) copy of the app. I don't think it can happen if you launch the new build from a command line, though. (So how plausible it is here might depend how Rik typically works.)

Comment 19

[Jonathan Kew [:jfkthame]]

(In reply to comment #17)
> OK, things are a bit clearer.
> 
> If I launch MinefieldDebug.app from the Finder, things work.
> If I launch from the Terminal, things don't work.

Hmm. So you can still reproduce the failure, if you launch your build from the Terminal? Strange indeed.

How about if you launch a mozilla-central nightly from the Terminal?

If this is limited to your local build, I'd still be interested to try it here. I have not been able to reproduce this behavior at all, regardless of how I launch Minefield. (I usually run it from a Terminal window.)

Comment 20

[Anthony Ricaud (:rik)]

I can reproduce it with yesterday's nightly build.
I've also started from a shell with an empty ~/.profile and I can reproduce.

However, on 2 other Mac in the office, I can't reproduce.

Comment 21

[Mike Shaver (:shaver emeritus)]

Evidence seems to point to this being a bad interaction with something on :rik's machine; we should work correctly on his machine, of course, but it shouldn't keep us from shipping FF4 to 429,999,999 other people. :-)