paper-button icon indicating copy to clipboard operation
paper-button copied to clipboard

paper button receives 'keyboard-focus' when refocusing tab

Open anthonytordillos opened this issue 10 years ago • 14 comments

If you click a paper-button, then unfocus and refocus the tab, paper-button receives the keyboard-focus class. It also looks like this happens with other elements (e.g. paper-icon-button), and it leads to a somewhat broken looking experience.

anthonytordillos avatar May 29 '15 22:05 anthonytordillos

I can confirm this problem, this happens on the official polymer-project website too.

kungufli avatar Jun 10 '15 15:06 kungufli

confirmed as well; similar things occur with radio-buttons, etc., which seems especially broken.

m4b avatar Jun 18 '15 19:06 m4b

@cdata Sigh. I think this might also be an instance of the "focus without a mouse down is automatically a keyboard focus" issue, which is technically not super true in the "re-activate tab" case :(

notwaldorf avatar Jun 18 '15 22:06 notwaldorf

This is related to https://github.com/PolymerElements/paper-radio-button/issues/33.

notwaldorf avatar Jun 19 '15 20:06 notwaldorf

This looks like it is still an issue as of merging https://github.com/PolymerElements/iron-behaviors/pull/23

@notwaldorf could you take a look?

tjsavage avatar Aug 04 '15 01:08 tjsavage

@tjsavage this isn't a new bug, it's been around forever (including 0.5). i think @cdata is our focus expert, unfortunately.

notwaldorf avatar Aug 04 '15 01:08 notwaldorf

Quick bump on this issue

tjsavage avatar Aug 24 '15 15:08 tjsavage

Ping?

anthonytordillos avatar Sep 28 '15 21:09 anthonytordillos

Gentle ping on this.

rictic avatar Oct 26 '15 18:10 rictic

Any update? Coming up on a year since this was filed.

anthonytordillos avatar Apr 14 '16 02:04 anthonytordillos

The reason why this still hasn't been fixed is because the platform gives us no reliable way of determining whether focus came from a mouse or keyboard (which, in Material Design, look different when focused). Currently, we rely on the state of the pointer (https://github.com/PolymerElements/iron-behaviors/blob/master/iron-button-state.html#L116), but the pointer will not be pressed when switching between tabs, so that is why it has "keyboard-focus". We are actively looking for other ways to fix this, but there doesn't seem to be any alternatives.

keanulee avatar Apr 15 '16 00:04 keanulee

Is there a reason we can't just listen for whether or not the tab is active on the window and then blur the focus? I tested this within the ready function of the paper-button element and this fixes the issue however I'm not sure where the right place for this would be or if there might be a better variation of this because I might not be thinking of other situations.

document.addEventListener('visibilitychange',function(){
	console.log("Changed");
	this.blur();
}.bind(this));

MichaelScript avatar May 22 '18 04:05 MichaelScript

hitting this bug five years later. any workarounds?

esurface avatar Sep 16 '20 21:09 esurface

Hey @esurface it seems unlikely that there will be significant changes to this component moving forward. It is possible that the issue could be taken up by someone in the community to be fixed. I'm happy to look at any PR someone might come up with to attempt a fix.

cdata avatar Sep 17 '20 20:09 cdata