258300 - Many character encoding is unselectable in setting of Default Character Encoding.

Status: RESOLVED FIXED

(Core :: XUL, defect)

Description

[hub-san]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a3) Gecko/20040904
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a3) Gecko/20040904

I cannot select character encoding of language setting which I want because
scroll bar is gone.  This problem happens at both "Languages" of "Navigator"
category and "Message Display" of "Mail & Newsgroups" category.  


Reproducible: Always
Steps to Reproduce:
1. Goto Mozilla->Preferences...->Navigator->Languages.
2. Select Character Encoding: -> Default Character Encoding.
(in Navigator category)

Actual Results:  
Many character encoding is unselectable because scroll bar is gone.  I cannot
select character encoding of language setting which I want.



Expected Results:  
All character encoding is selectable by using scroll bar.  I can select
character encoding of language setting which I want.


On MacOSX10.2.8, I confirmed this problem on Mozilla 2004-09-05-08-trunk
build(Classic theme).  But, Mozilla 2004-09-04-08-trunk didn't have this
problem.  Then, I confirmed this problem on Mozillla 2004-09-05-03-trunk
build(Linux gtk2+xft).  But, Mozilla 2004-09-04-03-trunk(gtk2+xft) didn't have
this problem.  It seemed that this bug occurred between 20040903 and 20040904. 
I searched CVS checkins of last three days.  Is this problem caused by bug
72747?  Or bug 252326 or bug 257920 or bug 250342?

Comment 1

[Boris Zbarsky [:bzbarsky]]

Chances are, this is bug 72747

Comment 2

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

Checkin range is roughly:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-09-04+06%3A00&maxdate=2004-09-05+04%3A00&cvsroot=%2Fcvsroot

Comment 3

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

It may have something to do with the parsing of the style attribute on the
xul:hbox inside the menupopup inside the menulist.  (Although there is a chance
that I could be seeing two separate bugs -- one in style data computation and
one in serialization.)

Comment 4

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

A pull-by-date build at 2004-09-04 17:00 -0700 doesn't show the bug.

Comment 5

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

Attachment: patch

Bizarrely enough, this seems to fix the bug.  I don't know:
 (1) why parsing style attributes in XBL involves serialization
 (2) why there wasn't a CSS error when the serialization was reparsed

Comment 6

[Boris Zbarsky [:bzbarsky]]

> (1) why parsing style attributes in XBL involves serialization

Binding instantiation is done by doing a deep CloneNode() on the binding's
content.  Both nsXULElement::CloneNode and nsGenericElement::CopyInnerTo
effectively do a GetAttr() followed by SetAttr() for each attribute.  Doing that
to the "style" attribute serializes and then reparses.

> (2) why there wasn't a CSS error when the serialization was reparsed

I'm not sure about this one... worth checking out, possibly.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 158160 [details] [diff] [review]
patch

r+sr=bzbarsky

Comment 8

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

Fix checked in to trunk, 2004-09-07 22:42 -0700.

Comment 9

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

(In reply to comment #6)
> Binding instantiation is done by doing a deep CloneNode() on the binding's
> content.  Both nsXULElement::CloneNode and nsGenericElement::CopyInnerTo
> effectively do a GetAttr() followed by SetAttr() for each attribute.  Doing
> that to the "style" attribute serializes and then reparses.

Wow. There must be a more efficient way to do it.

Comment 10

[Boris Zbarsky [:bzbarsky]]

> Wow. There must be a more efficient way to do it.

Probably, yes.  Even attributes other than style could be more efficient (eg no
need to convert from enums to strings and back).

File a bug on this, perhaps?

Comment 11

[Boris Zbarsky [:bzbarsky]]

*** Bug 258425 has been marked as a duplicate of this bug. ***

Comment 12

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

I see bug 258451 was filed.

Comment 13

[[e-mail]]

We could move that style to xul.css or popup.css if you like.