1187689 - [e10s] autocomplete popup for <input> with <datalist> sized differently from non-e10s mode

Status: RESOLVED FIXED

(Core :: Layout: Form Controls, defect)

Description

[Jonathan Kew [:jfkthame]]

Testcase:

  data:text/html,<input style="width:30px" list="foo">
    <datalist id="foo"><option>one<option>two<option>three<option>four<option>five

In non-e10s mode, the popup that appears when typing a character such as "t" appears to have a minimum width of around 100px, so in this example the options are all shown in full, with some extra space to the right.

However, in e10s the popup is only as wide as the actual <input> element, with the result that it shows a truncated form of the option "three", at least with default fonts etc on OS X. (Results could vary depending on font settings.)

I think having a minimum width for the popup (as in the non-e10s case) is probably a good thing; this becomes particularly apparent if you add more options to this example, such that a scrollbar appears and occupies half the available width, making the options completely unreadable.

Comment 1

[Jonathan Kew [:jfkthame]]

This is particularly troublesome in vertical writing modes, as the popup still renders horizontally (bug 1153311), but the <input> element typically has a width not much over 20px (based on the font-size/line-height of its vertical contents). As a result, the e10s-mode popup is so narrow that none of the suggestions can be read at all; they just show as "…".

Comment 2

[Jonathan Kew [:jfkthame]]

Attachment: Apply a minimum width to autocomplete popup in e10s mode

Here's a patch that aims to solve this by simply forcing a minimum width for the popup; this seems to give similar behavior to the non-e10s case. This at least keeps the popup somewhat usable in vertical mode, pending a proper solution to bug 1153311.

Comment 3

[Blake Kaplan (:mrbkap) (inactive)]

Comment on attachment 8639037 [details] [diff] [review]
Apply a minimum width to autocomplete popup in e10s mode

I looked for a bit to figure out where the min-width for the non-e10s case comes from but I couldn't find it. Felipe, do you know if this patch will match the e10s behavior with the non-e10s behavior?

Comment 4

[:Felipe Gomes (needinfo for replies!)]

Comment on attachment 8639037 [details] [diff] [review]
Apply a minimum width to autocomplete popup in e10s mode

Yeah, we also constrain the min-width in non-e10s to be 100px, here:
http://mxr.mozilla.org/mozilla-central/source/toolkit/content/widgets/autocomplete.xml?rev=4a1d6222e2f7#793

What's missing is adjusting for the zoom factor. We could take the patch like this, but it would be nice if we go the extra mile to also include that.

remote-browser.xul has a _fullZoom property that stores this value

Comment 5

[Jonathan Kew [:jfkthame]]

Comment on attachment 8639037 [details] [diff] [review]
Apply a minimum width to autocomplete popup in e10s mode

AFAICT from local testing, the autocomplete popup in e10s mode already accounts for full-zoom. (It must be factored into the rect that's being sent to the _initPopup function.)

I tried a testcase at various zoom levels and the popup grew to match the width of the (zoomed) input field no matter how far I zoomed in. So I don't think there's anything more to do here.

Comment 6

[:Felipe Gomes (needinfo for replies!)]

Comment on attachment 8639037 [details] [diff] [review]
Apply a minimum width to autocomplete popup in e10s mode

Review of attachment 8639037 [details] [diff] [review]:
-----------------------------------------------------------------

Ok, easier then!

Comment 7

[Jonathan Kew [:jfkthame]]

url:        https://hg.mozilla.org/integration/mozilla-inbound/rev/41ea066f291fb0d433d95a4e06e9aa4803a460d4
changeset:  41ea066f291fb0d433d95a4e06e9aa4803a460d4
user:       Jonathan Kew <[e-mail]>
date:       Tue Jul 28 20:10:58 2015 +0100
description:
Bug 1187689 - Apply a minimum width to autocomplete popup in e10s mode. r=felipe

Comment 8

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/41ea066f291f