191032 - [Camino]Text is not remeasured when font is changed and document is reloaded

Status: RESOLVED INACTIVE

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

Description

[Mark Mentovai]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.0.1) Gecko/20030128 Chimera/0.6+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.0.1) Gecko/20030128 Chimera/0.6+

If a font is changed in the Fonts tab of the Appearance preference pane,
and the user reloads the document to apply the changes, the old
measurements are used and the resultant rendered page may look funny if
the metrics of the old and new typefaces differ.

Reproducible: Always

Steps to Reproduce:
Start with the default Western font set to the proportional font, as
Times 14.
Visit http://bugzilla.mozilla.org/show_bug.cgi?id=184092#c5 .
Do Navigator:Preferences:Appearance:Fonts.
Switch Proportional (Serif) face to Lucida Grande 14 and close Preferences.
Command-R (reload)
Actual Results:  
The proportional font was changed to Lucida Grande 14, but the page was
redrawn using the measurements from Times 14.  Because Times is, in
general, narrower than Lucida Grande at the same point size, various
bits of text will overrun each other.

Reload again, and the text will be drawn properly.

When switching from Lucida Grande back to Times, gaps will be visible
instead of overruns.

Expected Results:  
The text should have been measured and drawn properly after the first
reload.

Actually, the page should have been rendered again after the font was
changed.  (And it should have been done properly.)

Note that if multiple windows are open, and a change is made to the font
selection, the change is applied to the background windows but not the
foreground window.  And the measurement bug is still present.  (This is probably
a separate bug.)

0.6.0+-2003012807/10.2.3

Comment 1

[Stephane Moureau]

Duplicate of bug 185957 ?

Comment 2

[Mark Mentovai]

I don't think so.  Bug 185957 is about the page not being redrawn with the new
fonts, which I mention here, but that's not what this bug is about.

This bug is about text not being remeasured.

Mark

Comment 3

[Greg K.]

Mark, please attach a couple of comparitive screen captures demonstrating the
problem. (They don't have to be huge, just some part of the page that looks wrong.)

Also, does this also happen using Mozilla? Please test it.

Comment 4

[Mark Mentovai]

Attachment: Initial view before changing font

These images were prepared using Chimera 0.6.0+-2003020507.

The bug is also present in Mozilla 1.3b-20030212.  Reassign it over there?

Comment 5

[Mark Mentovai]

Attachment: Changed typeface to Lucida Grande and reloaded.

Comment 6

[Mark Mentovai]

Attachment: Reloaded again with Lucida Grande

Comment 7

[Mark Mentovai]

Attachment: Changed typeface from Lucida Grande back to Times

Comment 8

[Greg K.]

Confirmed using Chimera/2003021707.

Comment 9

[Mike Pinkerton (not reading bugmail)]

mozilla bug

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Probably something (table code?) is botching the reflow reason.

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Actually, based on the comment that the problem is only happening in the
foreground window, I suspect that's wrong.  Perhaps something funny is going on
with nsPresContext::ClearStyleDataAndReflow .

Comment 12

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I'm unable to reproduce this in Mozilla, but I can reproduce it in Camino.

Could you give steps to reproduce for Mozilla?

Comment 13

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: patch

This fixes it.	I need to poke into the prefs code to figure out why this works
in other places.  This also makes Camino apply font pref changes immediately.

Comment 14

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Taking.

Comment 15

[Greg K.]

David, Pink, is that patch something we should include in Camino 0.8?

Comment 16

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

I don't suppose there's any chance that this patch still applies, is there?  

The remeasuring problem's certainly still present in Camino 0.9a1 and DeerPark
1.1a1, and one still has to switch prefPanes or close the prefs window for font
changes in Camino take effect.

Comment 17

[Simon Fraser [no longer active]]

David: do we still want that patch?

Comment 18

[Benjamin L. Russell]

(In reply to comment #13)
> Created an attachment (id=129888) [edit]
> patch
> 
> This fixes it.	I need to poke into the prefs code to figure out why this works
> in other places.  This also makes Camino apply font pref changes immediately.

My apologies if this seems too elementary a question, but how do I apply the patch?

Comment 19

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

mento, dbaron: can you confirm that the remeasuring issue has been fixed sometime between when I made comment 16 and now?  I've tried on bugzilla and a couple of other places (to rule out the bugzilla skin change being involved), and it seems fixed in Camino 1.0 (and a recent trunk).

Camino's font prefs not updating until you switch prefPanes or close the prefs, on the other hand, has gotten really annoying with some bugs I've been QAing recently ;) so that part is definitely still b0rken.

Comment 20

[Chris Lawson (gone)]

(In reply to comment #19)
> Camino's font prefs not updating until you switch prefPanes or close the prefs,
> on the other hand, has gotten really annoying with some bugs I've been QAing
> recently ;) so that part is definitely still b0rken.

Should we just go ahead and file a new bug on that? Does Apple give guidance anywhere about whether prefs should always commit edits in real time, or wait until the prefs window is closed, or what? I suspect this is not the only pref pane where we fail to commit edits until un-selecting/closing. (For instance, the General prefs pane doesn't currently do this either, though a patch I've written for fixing another bug brings this behaviour to it.)

cl

Comment 21

[Jonathan Kew [:jfkthame]]

Camino is ancient history; I don't think this is relevant any more.