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

Status: RESOLVED WORKSFORME

(Core :: Layout: Form Controls, defect)

Description

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: screenshot on Nightly (44)

Due to the fix of bug 1123654, dropdown list of <select size="1"> doesn't show enough items because of taller line-height.

Comment 1

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: screenshot on 38 ESR

Comment 2

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Looks like that listbox's <option>'s line-height doesn't have this bug.

Comment 3

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

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?

Comment 4

[Boris Zbarsky [: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.

Comment 5

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(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...).

Comment 6

[Boris Zbarsky [:bzbarsky]]

> 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...

Comment 7

[Boris Zbarsky [:bzbarsky]]

And in particular, in e10s mode the combobox dropdown is done in the _parent_ process, afaict.

Comment 8

[Jonathan Kew [:jfkthame]]

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.)

Comment 9

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

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.

Comment 10

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I cannot reproduce this bug anymore.