I encountered a small glitch in Firefox 6.0 on Mac OS X 10.6.8. I create a new window. I go to http://fr.wikipedia.org/w/index.php?title=Orcades&oldid=71187757#.C3.82ge_du_fer . I scroll up and down and up and down and up and down… In “Âge du fer”, the circumflex accent gets turned into a dieresis. Then, it completely disappears. Then, it re-appears as the correct circumflex accent. Then, in “Époque norvégienne”, the first accent goes away and then comes back… See screen film : http://screencast.com/t/0GubnxhHXfY Thanks for fixing this little bug. Nicolas
Does it really eat only the accents, or is the entire 1-2px high line of the page missing?
I noticed the bug only on the accents on a capital letter.
Maybe a screenshot would help?
Of course. So now I understand better why your first question, and I guess you did see my screen film : http://screencast.com/t/0GubnxhHXfY
Of course. So now I understand better why your first question, and I guess you did not see my screen film : http://screencast.com/t/0GubnxhHXfY
Ah, sorry, yes I couldn't see it. Will try that.
OK, I have now seen the video. I can't see anything like that on Win XP or linux. It could be something with OS X text rendering. Can you try Firefox 7?
Component: General → Layout: Text
Product: Firefox → Core
QA Contact: general → layout.fonts-and-text
Version: unspecified → 6 Branch
Please reopen with details if you can reproduce with a current version
Status: UNCONFIRMED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → INCOMPLETE
In Firefox 25.0 on Mac OS X 10.6.8, I reproduce the bug.
Status: RESOLVED → UNCONFIRMED
Resolution: INCOMPLETE → ---
As far as I can see, it looks like this, bug 696184 and bug 703940 are all manifestations of the same basic issue: the default sans-serif font we're using on OS X (Helvetica) has metrics that do not allow space for accents above uppercase letters within the ascent of the font; when you use a character such as Â, the circumflex (or at least part of it) extends beyond the font's nominal ascent line. And in some cases, at least, it seems we don't fully refresh parts of the glyph that fall outside the font's ascent/descent metrics. What's puzzling to me is that I can't reproduce this on OS X 10.7, despite trying various approaches; yet AFAICS, the same issue with accented Helvetica capitals extending beyond the font's ascent line is still present - the font hasn't been changed. So it looks like this may only affect 10.6, but I don't know why there's such a difference in behavior. Simple testcase: data:text/html;charset=utf-8,<div style="font:16px helvetica;height:2000px">Âge Press Cmd-A to "Select All", and you can see that the circumflex accent projects outside the bounds of the selection highlight, which I presume reflects the font's ascent and descent metrics. Scroll the page *slowly* (a pixel at a time) up and down, so that the glyph gradually disappears from view and then returns. As I understand it, on 10.6, the circumflex accent will not be repainted properly as the page is scrolled back to its original position (provided you go slowly); but on 10.7 I'm always seeing it fully painted. Nicolas, could you confirm the behavior of this testcase, please, to make sure I'm looking at the right thing? I'm not sure whether the real problem here is a font-related issue, or something more to do with invalidation or repainting... either way, why does the behavior vary depending on OS version? cc'ing a few extra people who might have some further insight.
Jon, thank you for taking interest in this problem. You are looking in the right direction. With your test case, I reproduce the problem in Firefox 25 on Mac OS X 10.6.8, and also on my new Mac, in Firefox 25.0.1 on Mavericks. Selecting all gives me this : screen photo http://pbrd.co/1amC2k7 Here is a bigger test I made, inpired by yours : data:text/html;charset=utf-8,<div style="font: 256px helvetica; height: 2000px;">Âme In Firefox 25.0.1 on Mavericks I get this : screen photo http://pbrd.co/1amCXkK You will see that even without scrolling the accent is eaten. Let's compare with Mavericks' Safari 7 : screen photo http://pbrd.co/1amDIu8 In Safari this is neat. When I select all, Firefox leaves the accent entirely out of the blue rectangle, whereas Safari takes the whole accent in the blue rectangle. The selection may involve a different problem, because selection in Firefox has always be **** (select a section in Wikipedia, and you will get 50 blue rectangles instead of one).
Are we actually including the glyph extents in the textframe overflow area? As far as I can tell, we still don't set gfxTextRunFactory::TEXT_NEED_BOUNDING_BOX for font sizes less than browser.display.auto_quality_min_font_size (20 by default), which leads to this bug. You should be able to tell by setting that pref to 1 or 0 or something. But I would definitely want to check with jdaggett's text performance test suite before doing that by default! (In reply to Nicolas Barbulesco from comment #11) > Here is a bigger test I made, inpired by yours : > > data:text/html;charset=utf-8,<div style="font: 256px helvetica; height: > 2000px;">Âme > > In Firefox 25.0.1 on Mavericks I get this : screen photo > http://pbrd.co/1amCXkK > You will see that even without scrolling the accent is eaten. > Let's compare with Mavericks' Safari 7 : screen photo http://pbrd.co/1amDIu8 This looks more like a line layout issue to do with the placement of the text baseline.
I also encounter this bug in Firefox 27 on Mavericks.
(In reply to Jonathan Kew (:jfkthame) from comment #10) > Simple testcase: > data:text/html;charset=utf-8,<div style="font:16px > helvetica;height:2000px">Âge > Scroll the page *slowly* (a pixel at a time) up and down, so that the glyph > gradually disappears from view and then returns. As I understand it, on > 10.6, the circumflex accent will not be repainted properly as the page is > scrolled back to its original position (provided you go slowly); but on 10.7 > I'm always seeing it fully painted. With Firefox 43.0.4 on Mac OS X 10.9.5, when I scroll * slowly *, in some cases the accent gets eaten, at least partially, so the Â looks like Ä.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 5 years ago → 2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 703940
You need to log in before you can comment on or make changes to this bug.