Closed Bug 1208297 Opened 9 years ago Closed 4 years ago

[e10s] Dropdown list doesn't show enough items even when there is enough space on Japanese Windows

Categories

(Core :: Layout: Form Controls, defect)

x86
Windows 10
defect

Tracking

()

RESOLVED WORKSFORME
Tracking Status
e10s - ---
firefox44 --- affected
firefox81 --- unaffected

People

(Reporter: masayuki, Unassigned)

References

()

Details

(Keywords: regression)

Attachments

(2 files)

Attached image screenshot on Nightly (44) (deleted) —
Due to the fix of bug 1123654, dropdown list of <select size="1"> doesn't show enough items because of taller line-height.
Looks like that listbox's <option>'s line-height doesn't have this bug.
If you know, I'd like you to teach me the mechanism. The dropdown list's font style is the style of XUL's <menuitem> element which is specified here: http://mxr.mozilla.org/mozilla-central/source/toolkit/themes/windows/global/menu.css?rev=c868ce24344c&mark=197-197,205-205#195 However, I cannot find the binding declaration of ::-moz-dropdown-list to XUL elements. I think that for fixing this bug, we should specify |font: -moz-list;| to the hidden XUL elements in ::-moz-dropdown-list. However, it seems that it's impossible to do that from layout/style/forms.css. Then, there should be another approach, we should overwrite the font rules in the menu.css only when <menuitem> is a part of ::-moz-dropdown-list. However, I've not found the way to distinguish the purpose of <menuitem>. bz, do you know something about this?
Flags: needinfo?(bzbarsky)
> If you know, I'd like you to teach me the mechanism. Mechanism for which? > The dropdown list's font style is the style of XUL's <menuitem> element That seems fairly unlikely. Why would that matter for <html:select> rendering? > However, I cannot find the binding declaration of ::-moz-dropdown-list to XUL elements. What does XUL have to do with the behavior of <html:select> at all? Are you testing in e10s mode or non-e10s mode? Because combobox dropdowns in e10s mode are all sorts of messed up and not done at all the way they are in non-e10s mode.... So I guess it's possible that the XUL styles would affect those somehow. But that's just a bug in the e10s implementation, and fixing, say, bug 910022 should fix that.
Flags: needinfo?(bzbarsky)
Depends on: 910022
(In reply to Boris Zbarsky [:bz] from comment #4) > > If you know, I'd like you to teach me the mechanism. > > Mechanism for which? I meant that the mechanism how the dropdown list of <html:select> was created with <xul:menuitem>. I don't understand the reason why the style in menu.css was applied to <html:select> since I cannot see any XUL element creation in frame constructor. > > The dropdown list's font style is the style of XUL's <menuitem> element > > That seems fairly unlikely. Why would that matter for <html:select> > rendering? Because in menu.css, <xul:menuitem> has |font: message-box;| (I don't know why not |font: menu;|). On the other hand, dropdown list of <html:select> should be |font: -moz-list;|. The Japanese message box font has much taller font metrics than the font for list item. Therefore, the number of items shown in drowpdown list is less than nsListControlFrame has expected. > > However, I cannot find the binding declaration of ::-moz-dropdown-list to XUL elements. > > What does XUL have to do with the behavior of <html:select> at all? If it's possible, XUL element style shouldn't affect to the dropdown list of <html:select>. > Are you testing in e10s mode or non-e10s mode? Because combobox dropdowns > in e10s mode are all sorts of messed up and not done at all the way they are > in non-e10s mode.... So I guess it's possible that the XUL styles would > affect those somehow. But that's just a bug in the e10s implementation, and > fixing, say, bug 910022 should fix that. Oh, I really? That makes sense if that is the cause. I'll check with non-e10s mode on Windows later (I'm using Mac now...).
> since I cannot see any XUL element creation in frame constructor In which process? ;) I bet what you're seeing is precisely the e10s brokenness...
And in particular, in e10s mode the combobox dropdown is done in the _parent_ process, afaict.
That's correct; and the parent process uses a <xul:menulist> popup, even though it was an HTML <select> in the child. (This is also the reason <select> doesn't work well in vertical writing modes; see bug 1170129.)
Sorry for the delay. I confirmed that this is e10s only bug. I think that even if bug 910022 won't be fixed by first release of e10s mode in release build, we should fix this bug by then. Using taller system font than MS ShellDlg 2 causes showing less items in the dropdown list.
Summary: Dropdown list doesn't show enough items even when there is enough space on Japanese Windows → [e10s] Dropdown list doesn't show enough items even when there is enough space on Japanese Windo[ws
tracking-e10s: --- → -

I cannot reproduce this bug anymore.

Assignee: masayuki → nobody
Severity: normal → --
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → WORKSFORME
Summary: [e10s] Dropdown list doesn't show enough items even when there is enough space on Japanese Windo[ws → [e10s] Dropdown list doesn't show enough items even when there is enough space on Japanese Windows
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: