Re: Form Autofill Highlight/Preview implementation for "Select"

[Markus Stange]

Hi Vance,

nice to meet you.

I'm not sure I've completely understood the problem, but I'll try to answer anyway.

The menu that we use for <select> menus on Mac is still a regular XUL <menupopup>, even if it looks a lot like a real native menu. The appearance comes from -moz-appearance: menupopup and -moz-appearance: menuitem, and from how those values are handled in nsNativeThemeCocoa.mm and friends.

Menu items are highlighted if menuactive="true" is set on the <menuitem> element, the same as on the other platforms.

(The exact check that makes the difference here is at line http://searchfox.org/mozilla-central/rev/9bbb2bd7c715d9a76e0a0bde043dad41021ea7c9/widget/cocoa/nsNativeThemeCocoa.mm#3887 .)

Does this help?

Markus

On Wed, Mar 1, 2017 at 9:43 AM, Vance Chen <vc...@mozilla.com> wrote:

Hi Markus,

This is Vance from Mozilla Taipei office, nice to meet you via email !

I am reaching out to you because now Taipei FE team is working on Form Autofill and there is one feature we might need to consult you.
The feature is about highlight/preview of the Form Autofill, the spec is here(page 11 and page 12). We need to support that not only for the inputs filed but for Select element as well. And for now we have no idea how to do that for Select since the select is done by Widgets. We discussed with Matt(:MattN) and he suggested us to reach out to you, so here I am :). It would be very helpful if you can shed some lights and point us to the right direction regarding how we might be able to do the highlight/preview on Select.

Thanks!

Vance

[Luke Chang]

Hi Markus,

Nice to meet you, too. This is Luke. I'm working on Form Autofill and can help to clarify this problem.

It's not about <menupopup>. In Form Autofill, we're going to implement a feature, which is able to programmatically change a <select> itself's background color (highlight) and the displayed text (preview) so users can preview how many data will be filled in. The challenge here is that we cannot modify any content-perceivable attribute (CSS, placeholder, etc) since we don't want data be leaked before users confirm it. This feature is very similar to Chrome's so I recorded theirs as a reference [1].

This feature also needs to apply to <input> that we intend to do it via AnonymousContent. However, we know the <select> element is rendered by widgets by default and will fallback to gecko styling only when certain styles (e.g. background-color) are set. So there are two questions for now:

1. If we want to do preview and highlight on <select> with OS native styling, is it possible not to modify the widget code? (Modifying the widget code means we need to modify at least three OS's version, right?)
2. If we want to use AnonymousContent on <select> as well, does that mean we can only apply it to gecko styling? If so, is there any way to force a <select> to fallback without setting CSS attributes?

It would be very helpful if you can give us some hints or correct me if I misunderstand anything above. Thanks.

Regards,

Luke

[1] https://drive.google.com/a/mozilla.com/file/d/0BxRVL4PkLT8Qa2l4dlYxUVBjMWs/view?usp=sharing

_______________________________________________
autofill mailing list
auto...@lists.mozilla.org
https://lists.mozilla.org/listinfo/autofill

[Markus Stange]

Ah, I see, thanks for clarifying.

I think the anonymous content solution that you'll be using for <input> will also work for <select>. Only the <select>'s background is drawn by widget; the text is drawn by Gecko on top.

Markus

[Markus Stange]

Oh, I think I was confused again. Let my try one more time :-)

It's not the text that is problematic, it's the <select>'s background color...

Yes, that is going to be a problem. Setting an override background color will make the widget fall back to Gecko styling, which can be a very jarring transition because it'll look very different and might make elements shift around because of different geometries.

I'll need to think about how best to address this problem. In Chrome, they have widget code that allows them to draw a native-like widget with a specified background color. We don't have that so every time somebody sets a background-color on a <select> element it looks quite ugly. Maybe we should just do what they do - instead of falling back to complete Gecko styling when there's a border or a background on a <select>, fall back to a "native-like" rendering that respects the specified borders and backgrounds. This might have web compat implications, though... not sure what to do about that.

By the way, doesn't this same problem also exist for <input>? Text input fields also look slightly different if they're rendered by widget vs rendered by Gecko styling. But the difference is much more subtle, so it's probably not a big problem.

Markus

[Luke Chang]

Hi Markus,

Sorry for my late reply. I agree that it isn't a good idea to make the widget fallback frequently due to the jarring transition.

In <input>, we are planning to add an anonymous content with the preview text inside, which is like what the placeholder does. We were planning to set background color for the anonymous content instead of <input> itself to avoid making it fallback to gecko styling. However, I just realized that the internal div cannot fill the entire input area with the specified color when it's rendered by widgets. So yes, the background-color problem also exists for <input>. A "native-like" rendering may be an approach, but also a big task. We're still looking for proper solutions or workarounds.

Regarding the preview text, as you mentioned in the previous mail, the anonymous content should also apply to <select> so we'll try this way for the text first. Thank you for your suggestions.

Regards,

Luke