bug#43218: EWW handles default answer incorrectly when changing a select

[Lars Ingebrigtsen <larsi@gnus.org>]

Nicolas Graner <nicolas.graner@universite-paris-saclay.fr> writes:

> Activate the select and change its value to 'two'.
> Activate it again and answer <RET> to the prompt for value: the
> displayed value returns to 'one'.
>
> This is not critical as this situation is rare and the value sent to the
> server will be correct anyway, but it is confusing to the user who does
> not usually know the value of each option.

That's true...  there's also a general problem with how the values are
selected: We're doing a completing-read over the display names, and then
mapping that back to the values.  But this is perfectly valid:

<select name="a">
<option value="1">one</option>
<option value="2">one</option>
</select>

But there's no way to select the second value in eww.

Unfortunately, the Emacs primitives for prompting are very
text-oriented, and don't allow putting properties on the values we're
completing over, not even with:

---
minibuffer-allow-text-properties is a variable defined in ‘src/minibuf.c’.
Its value is nil

  Probably introduced at or before Emacs version 20.

Documentation:
Non-nil means ‘read-from-minibuffer’ should not discard text properties.
This also affects ‘read-string’, but it does not affect ‘read-minibuffer’,
‘read-no-blanks-input’, or any of the functions that do minibuffer input
with completion; they always discard text properties.
---

I wonder what the logic behind this is?  And I also have a vague feeling
I've asked this before...

Perhaps Stefan knows and or remembers.  :-)

So the test case is:

(let ((minibuffer-allow-text-properties t))
  (completing-read "Foo: " (list (propertize "foo" 'data 'bar))
                   nil 'require-match))
=> "foo"

instead of #("foo" 0 3 (data bar))

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no