GNU bug report logs - #81107
31.0.60; eww: HTML button elements are not tab-stoppable

Previous Next

To reply to this bug, email your comments to 81107 AT debbugs.gnu.org.
There is no need to reopen the bug first.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Amin Bandali <bandali <at> gnu.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.60; eww: HTML button elements are not tab-stoppable
Date: Sat, 23 May 2026 10:07:48 -0400

Per the title, HTML <button> elements rendered in eww are currently
not tab-stoppable, leading to poorer usability and accessibility.

For what it's worth, for buttons elements with a <input type="submit">
markup eww does the correct thing with regards to this, so we just
have to fix eww to do the right thing similarly for <button> elements.

I'll attach a patch for this shortly, which I intend to install on
emacs-31 later.

Message #8 received at 81107 <at> debbugs.gnu.org (full text, mbox):

From: Amin Bandali <bandali <at> gnu.org>
To: 81107 <at> debbugs.gnu.org
Subject: Re: 31.0.60; eww: HTML button elements are not tab-stoppable
Date: Sat, 23 May 2026 13:04:22 -0400

[Message part 1 (text/plain, inline)]

tags -1 patch
thanks

Amin Bandali wrote:

> [... 6 lines elided]
>
> I'll attach a patch for this shortly, which I intend to install on
> emacs-31 later.

Patch attached.

[0001-Make-HTML-button-elements-tab-stoppable-in-eww-bug-8.patch (text/x-diff, attachment)]

Message #11 received at 81107 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Amin Bandali <bandali <at> gnu.org>, 81107 <at> debbugs.gnu.org
Subject: Re: bug#81107: 31.0.60; eww: HTML button elements are not
 tab-stoppable
Date: Sat, 23 May 2026 10:21:59 -0700

On 5/23/2026 10:04 AM, Amin Bandali wrote:
> Patch attached.

> +      (put-text-property start (1+ start) 'help-echo "Button")
> +      (put-text-property start (1+ start) 'shr-tab-stop t))))

Should these properties be added in 'eww-form-submit' instead? I think 
we'd want tab stops when we see <input type="submit"> in the HTML too.

Message #14 received at 81107 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Amin Bandali <bandali <at> gnu.org>
Cc: 81107 <at> debbugs.gnu.org
Subject: Re: bug#81107: 31.0.60;
 eww: HTML button elements are not tab-stoppable
Date: Sat, 23 May 2026 20:26:41 +0300

> From: Amin Bandali <bandali <at> gnu.org>
> Date: Sat, 23 May 2026 13:04:22 -0400
> 
> Amin Bandali wrote:
> 
> > [... 6 lines elided]
> >
> > I'll attach a patch for this shortly, which I intend to install on
> > emacs-31 later.
> 
> Patch attached.

Thanks, but please explain why this needs to be installed on the
release branch.  What are the problems the current code has, and in
what situations they will happen?  Bonus points for providing a
reproduction recipe.

In general, we would like to avoid at this time installing changes on
the release branch that can wait until Emacs 32.  the reason is not to
make changes which might have unintended consequences and thus delay
the release of Emacs 31.1.  The assumption is that code which didn't
draw any significant bug reports until now cannot be too bad.

Please reconsider this change from that POV.

Message #17 received at 81107 <at> debbugs.gnu.org (full text, mbox):

From: Amin Bandali <bandali <at> gnu.org>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 81107 <at> debbugs.gnu.org
Subject: Re: bug#81107: 31.0.60; eww: HTML button elements are not
 tab-stoppable
Date: Sat, 23 May 2026 23:02:59 -0400

Jim Porter wrote:

> On 5/23/2026 10:04 AM, Amin Bandali wrote:
>> Patch attached.
>
>> +      (put-text-property start (1+ start) 'help-echo "Button")
>> +      (put-text-property start (1+ start) 'shr-tab-stop t))))
>
> Should these properties be added in 'eww-form-submit' instead? I think
> we'd want tab stops when we see <input type="submit"> in the HTML too.

Please note that per my original message, for <input type="submit">
buttons eww already does the right thing, because it adds those
properties at the end of `eww-tag-input' for all input types,
including those of type="submit" which act as buttons.

We *could* add those properties in `eww-form-submit' instead, which
would eliminate the need for the `eww-tag-button' that my patch
introduces, but then we'd have to change `eww-tag-input' to make the
addition of those faces conditional (only if type != "submit") which
would complicate my patch a bit.  We *could* consider doing that, but
I wanted to keep the change as simple and small as possible since
I had intended it for emacs-31.

Message #20 received at 81107 <at> debbugs.gnu.org (full text, mbox):

From: Amin Bandali <bandali <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 81107 <at> debbugs.gnu.org
Subject: Re: bug#81107: 31.0.60; eww: HTML button elements are not
 tab-stoppable
Date: Sun, 24 May 2026 00:16:23 -0400

Eli Zaretskii wrote:

> [... 11 lines elided]
>
> Thanks, but please explain why this needs to be installed on the
> release branch.  What are the problems the current code has, and in
> what situations they will happen?  Bonus points for providing a
> reproduction recipe.
>
> In general, we would like to avoid at this time installing changes on
> the release branch that can wait until Emacs 32.  the reason is not to
> make changes which might have unintended consequences and thus delay
> the release of Emacs 31.1.  The assumption is that code which didn't
> draw any significant bug reports until now cannot be too bad.
>
> Please reconsider this change from that POV.

Thanks for your comments, and my apologies for not providing more
explanation/justification as to why I'd intended it for emacs-31.

The problem with eww's current code is that it does not properly set up
<button> elements for user interaction: they are not given focus when
hitting TAB.  This is confusing and counter-intuitive, not least because
eww already does the right thing for <input type="submit"> buttons,
which are focusable with TAB.  There is no reason <button> elements
should behave any differently in this regard.  Indeed, all the other
browsers I tested (Firefox, Chromium, Lynx, Dillo) treat <button> and
<input type="submit"> exactly the same in this regard, giving them focus
with TAB.

To reproduce/test this, create a test.html file with these contents:

  <!DOCTYPE html><html><head><title>button test</title></head><body>
  <button>first &lt;button&gt;</button><br />
  <input type="submit" value="first &lt;input&gt; button" /><br />
  <button>second &lt;button&gt;</button><br />
  <input type="submit" value="second &lt;input&gt; button" />
  </body></html>

Open it in eww, and notice how "first <button>" and "second <button>"
are not given focus with TAB and are skipped.  Then open the file in
other web browsers and compare the behaviour.

I opened the bug report and wrote a patch as soon as I noticed the bug.
I believe the reason it may not have been noticed or reported earlier
may be that the <input type="submit"> markup for buttons predates and is
more commonly used than the <button> markup.  My reasons for intending
this for emacs-31 are mainly that this is clearly a bug and per Sean's
message announcing the emacs-31 feature freeze "all fixes should go to
emacs-31", my impression that we're still fairly early in the freeze and
it would be nice to have this bug fixed in the upcoming emacs release,
and my proposed fix being small and self-contained (all my proposed
change does is that for <button> elements, in addition to calling
`eww-form-submit', also add the `shr-tab-stop' and `help-echo' text
properties that `eww-tag-input' adds for <input> elements, including
for those of type="submit" which also act as buttons).

I hope this helps clarify my proposed change and why it was aimed at
emacs-31.  Of course if you still believe that it's not appropriate for
emacs-31 then I'll concede and apply it to master instead.

Thanks,
amin

Message #23 received at 81107 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Amin Bandali <bandali <at> gnu.org>
Cc: 81107 <at> debbugs.gnu.org
Subject: Re: bug#81107: 31.0.60; eww: HTML button elements are not
 tab-stoppable
Date: Sun, 24 May 2026 08:36:56 +0300

> From: Amin Bandali <bandali <at> gnu.org>
> Cc: 81107 <at> debbugs.gnu.org
> Date: Sun, 24 May 2026 00:16:23 -0400
> 
> Eli Zaretskii wrote:
> 
> > In general, we would like to avoid at this time installing changes on
> > the release branch that can wait until Emacs 32.  the reason is not to
> > make changes which might have unintended consequences and thus delay
> > the release of Emacs 31.1.  The assumption is that code which didn't
> > draw any significant bug reports until now cannot be too bad.
> >
> > Please reconsider this change from that POV.
> 
> Thanks for your comments, and my apologies for not providing more
> explanation/justification as to why I'd intended it for emacs-31.
> 
> The problem with eww's current code is that it does not properly set up
> <button> elements for user interaction: they are not given focus when
> hitting TAB.  This is confusing and counter-intuitive, not least because
> eww already does the right thing for <input type="submit"> buttons,
> which are focusable with TAB.  There is no reason <button> elements
> should behave any differently in this regard.  Indeed, all the other
> browsers I tested (Firefox, Chromium, Lynx, Dillo) treat <button> and
> <input type="submit"> exactly the same in this regard, giving them focus
> with TAB.
> 
> To reproduce/test this, create a test.html file with these contents:
> 
>   <!DOCTYPE html><html><head><title>button test</title></head><body>
>   <button>first &lt;button&gt;</button><br />
>   <input type="submit" value="first &lt;input&gt; button" /><br />
>   <button>second &lt;button&gt;</button><br />
>   <input type="submit" value="second &lt;input&gt; button" />
>   </body></html>
> 
> Open it in eww, and notice how "first <button>" and "second <button>"
> are not given focus with TAB and are skipped.  Then open the file in
> other web browsers and compare the behaviour.

Thanks.  According to this, the problem is a minor one: the buttons do
work, but moving between buttons and links with TAB misses these
buttons, so the user will have to use less convenient and more tedious
methods of movement.

> I opened the bug report and wrote a patch as soon as I noticed the bug.
> I believe the reason it may not have been noticed or reported earlier
> may be that the <input type="submit"> markup for buttons predates and is
> more commonly used than the <button> markup.  My reasons for intending
> this for emacs-31 are mainly that this is clearly a bug and per Sean's
> message announcing the emacs-31 feature freeze "all fixes should go to
> emacs-31", my impression that we're still fairly early in the freeze and
> it would be nice to have this bug fixed in the upcoming emacs release,
> and my proposed fix being small and self-contained (all my proposed
> change does is that for <button> elements, in addition to calling
> `eww-form-submit', also add the `shr-tab-stop' and `help-echo' text
> properties that `eww-tag-input' adds for <input> elements, including
> for those of type="submit" which also act as buttons).

The patch replaces eww-form-submit with the new eww-tag-button in the
general-purpose function eww-display-document.  Thus, it affects
display of all the documents that have buttons.  What would happen if
the new function you added, however simple, has a bug?

Thus, the alternative of making the change in eww-form-submit sounds
safer to me for the release branch.  (We could also install what you
consider to be a cleaner patch on master and the safer one on
emacs-31, of course.)

Message #26 received at 81107 <at> debbugs.gnu.org (full text, mbox):

From: Amin Bandali <bandali <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 81107 <at> debbugs.gnu.org
Subject: Re: bug#81107: 31.0.60; eww: HTML button elements are not
 tab-stoppable
Date: Sun, 24 May 2026 11:15:51 -0400

[Message part 1 (text/plain, inline)]

Eli Zaretskii wrote:

> [... 39 lines elided]
>
> Thanks.  According to this, the problem is a minor one: the buttons do
> work, but moving between buttons and links with TAB misses these
> buttons, so the user will have to use less convenient and more tedious
> methods of movement.

Thanks.  Yes.  Though I'd say for folks who rely on assistive
technologies it might be more than a minor inconvenience.

>> I opened the bug report and wrote a patch as soon as I noticed the bug.
>> I believe the reason it may not have been noticed or reported earlier
>> may be that the <input type="submit"> markup for buttons predates and is
>> more commonly used than the <button> markup.  My reasons for intending
>> this for emacs-31 are mainly that this is clearly a bug and per Sean's
>> message announcing the emacs-31 feature freeze "all fixes should go to
>> emacs-31", my impression that we're still fairly early in the freeze and
>> it would be nice to have this bug fixed in the upcoming emacs release,
>> and my proposed fix being small and self-contained (all my proposed
>> change does is that for <button> elements, in addition to calling
>> `eww-form-submit', also add the `shr-tab-stop' and `help-echo' text
>> properties that `eww-tag-input' adds for <input> elements, including
>> for those of type="submit" which also act as buttons).
>
> The patch replaces eww-form-submit with the new eww-tag-button in the
> general-purpose function eww-display-document.  Thus, it affects
> display of all the documents that have buttons.  What would happen if
> the new function you added, however simple, has a bug?

Sure, that's a fair point.  Though updating eww-form-submit also
affects <input type="submit"> buttons, but that may be fine.

> Thus, the alternative of making the change in eww-form-submit sounds
> safer to me for the release branch.  (We could also install what you
> consider to be a cleaner patch on master and the safer one on
> emacs-31, of course.)

The new attached patch is how that might look like.

There's one visible side effect with this patch: the help-echo message
for <input type="submit"> buttons has been changed from "Input field"
to "Button".  I think the latter is more specific, so this change is
okay from my POV, but if there's a strong preference to maintain the
current help-echo message for <input type="submit"> then I can check
the tag (using dom-tag) in eww-form-submit to set different help-echo
messages accordingly.

[0001-Make-HTML-button-elements-tab-stoppable-in-eww.patch (text/x-diff, attachment)]

Message #29 received at 81107 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Amin Bandali <bandali <at> gnu.org>
Cc: 81107 <at> debbugs.gnu.org
Subject: Re: bug#81107: 31.0.60; eww: HTML button elements are not
 tab-stoppable
Date: Sun, 24 May 2026 12:01:42 -0700

On 5/23/2026 8:02 PM, Amin Bandali wrote:
> Jim Porter wrote:
> 
>> On 5/23/2026 10:04 AM, Amin Bandali wrote:
>>> Patch attached.
>>
>>> +      (put-text-property start (1+ start) 'help-echo "Button")
>>> +      (put-text-property start (1+ start) 'shr-tab-stop t))))
>>
>> Should these properties be added in 'eww-form-submit' instead? I think
>> we'd want tab stops when we see <input type="submit"> in the HTML too.
> 
> Please note that per my original message, for <input type="submit">
> buttons eww already does the right thing, because it adds those
> properties at the end of `eww-tag-input' for all input types,
> including those of type="submit" which act as buttons.

Ah, I see now. I didn't quite follow that sentence the first time 
around. Some of the EWW code is a bit twisty-turny, as in this case...

Message #34 received at 81107 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Amin Bandali <bandali <at> gnu.org>
Cc: 81107 <at> debbugs.gnu.org
Subject: Re: bug#81107: 31.0.60; eww: HTML button elements are not
 tab-stoppable
Date: Sat, 30 May 2026 14:14:21 +0300

> From: Amin Bandali <bandali <at> gnu.org>
> Cc: 81107 <at> debbugs.gnu.org
> Date: Sun, 24 May 2026 11:15:51 -0400
> 
> Eli Zaretskii wrote:
> 
> > The patch replaces eww-form-submit with the new eww-tag-button in the
> > general-purpose function eww-display-document.  Thus, it affects
> > display of all the documents that have buttons.  What would happen if
> > the new function you added, however simple, has a bug?
> 
> Sure, that's a fair point.  Though updating eww-form-submit also
> affects <input type="submit"> buttons, but that may be fine.
> 
> > Thus, the alternative of making the change in eww-form-submit sounds
> > safer to me for the release branch.  (We could also install what you
> > consider to be a cleaner patch on master and the safer one on
> > emacs-31, of course.)
> 
> The new attached patch is how that might look like.

Thanks, please install it.

> There's one visible side effect with this patch: the help-echo message
> for <input type="submit"> buttons has been changed from "Input field"
> to "Button".  I think the latter is more specific, so this change is
> okay from my POV, but if there's a strong preference to maintain the
> current help-echo message for <input type="submit"> then I can check
> the tag (using dom-tag) in eww-form-submit to set different help-echo
> messages accordingly.

I think the new help-echo is okay.

Message #39 received at 81107-done <at> debbugs.gnu.org (full text, mbox):

From: Amin Bandali <bandali <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 81107-done <at> debbugs.gnu.org
Subject: Re: bug#81107: 31.0.60; eww: HTML button elements are not
 tab-stoppable
Date: Sat, 30 May 2026 10:24:28 -0400

Eli Zaretskii wrote:

> [... 20 lines elided]
>
> Thanks, please install it.

Thanks Eli, done.

> [... 7 lines elided]
>
> I think the new help-echo is okay.

Great, thanks again. :)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.