Open Bug 633174 Opened 14 years ago Updated 2 years ago

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

Categories

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

x86
macOS
defect

Tracking

()

REOPENED
Tracking Status
blocking2.0 --- -

People

(Reporter: rik, Unassigned)

References

()

Details

(Keywords: regression)

After bug 499292 has landed, the text is not displayed even after the timeout.
This looks like a blocker to me....
Blocks: 499292
blocking2.0: --- → ?
Component: Style System (CSS) → Layout: Text
QA Contact: style-system → layout.fonts-and-text
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/
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.
(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?
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.
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
(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.
Here is the output when loading with the NSPR_LOG_MODULES http://pastebin.mozilla.org/1048344
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.
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.
If this isn't fixed by bug 633500, I think we should back out bug 499292 for FF4.
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.
(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?)
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.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
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?
(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?
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.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
(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.)
(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.)
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.
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. :-)
blocking2.0: ? → -
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.