dynamically populated menulists show "..." instead of values

RESOLVED DUPLICATE of bug 623922

Status

()

Core
XUL
RESOLVED DUPLICATE of bug 623922
7 years ago
7 years ago

People

(Reporter: Jonathan Kamens, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

7 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.6.17-1.fc14 Firefox/3.6.17 GTB7.1
Build Identifier: Mozilla/5.0 (X11; Linux x86_64; rv:7.0a1) Gecko/20110624 Thunderbird/7.0a1

My TB add-on, Send Later 3, has a dialog with several menulists in it. The values in these menulists are populated by my javascript code, not hard-coded in the XUL.

IN TB 3.1.10, the menulists are displayed properly after the values are populated. In the TB nightly trunk build as of today, however, they have "..." displayed in them instead of displaying the correct values.

I'm going to attach TB3.1.10.png, showing the correct layout, TBnightly.png, showing the incorrect layout, and prompt.xul, showing the XUL that produces the dialog in question.


Reproducible: Always
(Reporter)

Comment 1

7 years ago
Created attachment 541887 [details]
correct layout in TB 3.1.10
(Reporter)

Comment 2

7 years ago
Created attachment 541888 [details]
incorrect layout in TB nightly build
(Reporter)

Comment 3

7 years ago
Created attachment 541889 [details]
XUL file that creates the dialog
Attachment #541889 - Attachment mime type: application/octet-stream → text/plain
There are no form controls here...

roc, could this be due to text-overflow changes somehow?
Component: Layout: Form Controls → XUL
QA Contact: layout.form-controls → xptoolkit.widgets

Comment 5

7 years ago
Related to Bug 623922 ?
(In reply to comment #4)
> There are no form controls here...
> 
> roc, could this be due to text-overflow changes somehow?

I wouldn't have thought text-overflow could affect XUL labels; there are no blocks in sight.

A regression range would be really useful.
(Reporter)

Comment 7

7 years ago
It works properly in nightly build 2010-09-13-06-comm-central and is broken in 2010-09-13-16-comm-central. Does that help? I can't figure out how to narrow it down further than that... I'm not particularly experienced with hg or with the ins and outs of the Mozilla source tree or build system, so I don't know how to figure out what was checked into the entire tree between those two times, nor how to update my working directory as of a particular time or revision to try to identify the revision that is the culprit. If you can offer any quick advice on those things, I'm glad to do further research.
You can see what was pushed in that range here:
http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2010-09-13+00%3A00&enddate=2010-09-13+18%3A00

FWIW, the regression range is a couple of days earlier than bug 623922
(Last good nightly: 2010-09-15 First bad nightly: 2010-09-16)
according to bug 623922 comment 6.

Still, it's probably worth waiting a few more days for that to land
to see if it fixes this bug too... since it does look very similar.
Depends on: 623922
(Reporter)

Comment 9

7 years ago
Confirmed that the fix to 623922 fixed this as well, so dup'ing it.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 623922
You need to log in before you can comment on or make changes to this bug.