polymerelements/iron-behaviors

Behaviors that manage control states like 'focused', 'disabled', and 'active'

iron-behaviors's Issues

iron-control-state: add tabindex to hostAttributes

I'm assuming the point of iron-control-state is to make an element "focusable". If that's true, then the element must have a tabindex attribute. Otherwise, the browser does not consider the item focusable and won't fire the focus event. Knowing that, shouldn't elements implementing iron-control-state always have a tabindex attribute? Or is this omitted on purpose?

drop polymer-legacy

is it possible to drop polymer-legacy dependency ? it's really bloating bundles

and I also noticed

import {dom} from '@polymer/polymer/lib/legacy/polymer.dom.js';

is not used, can we safely delete it ?

Make _asyncClick easier to test, or provide a test helper

MockInteractions.pressAndReleaseKeyOn uses Polymer.Base.async to queue the keyUp event.

IronButtonState._asyncClick uses this.async to queue the click event, with a delay of 1.

This means test code has to do this:

MockInteractions.pressEnter(foo);
Polymer.dom.flush();  // flush MockInteraction's async call
foo.async(function() {
  // test foo
}, 1);  // schedule a setTimeout with a delay >= 1, so it runs after _asyncClick

The async call must have a delay greater than or equal to the one used in _asyncClick thanks to step 13. If you ever change the delay here, say from 1 to 10, my test code will fail.

(The Polymer.dom.flush() in the above is extraneous, but included for clarity.)

It would be nice if I could just do:

MockInteractions.pressEnter(foo);
Polymer.dom.flush();  // flush all the things
// test foo

or even:

MockInteractions.pressEnter(foo);
Polymer.dom.flush();  // flush MockInteraction's async call
Polymer.dom.flush();  // flush IronButtonState's async call
// test foo

so I don't have to hard-code constants and keep them up-to-date with _asyncClick.

IronControlState _focusBlurHandler not handling focus events of slotted elements.

Description

In Polymer 3 , when a component using iron-control-state behavior has a slotted component that raises a 'focus' event, the parent component's focused property is set. This traps the focus on the _focusableElement in components using paper-input-behavior like 'paper-input'.

Example :

<paper-input label="username">
  <paper-icon-button slot="suffix" icon="clear"></paper-icon-button>
</paper-input>

The user is not able to move the focus to the paper-icon-button using the tab key, as the 'input' gets focused due paper-input-behavior.

Fix could involve checking the event.target before updating the focused property of the component.

_focusBlurHandler: function(event) {
   // Polymer takes care of retargeting events in shadowRoot.
   if(event.target === this){
      this._setFocused(event.type === 'focus');
   }
   return;
}

This issue seems to be the cause of paper-input issue #631.

Expected outcome

Slotted element's focus and blur events should not affect the component.

Actual outcome

Slotted element's 'focus' event sets focused property in the component.

Live Demo

Paper input demo page. Section Inputs can have prefixes and suffixes

Steps to reproduce

Available in paper-input issue #631.

Browsers Affected

• Chrome
• Firefox
• Safari 9
• Safari 8
• Safari 7
• Edge
• IE 11
• IE 10

Observer's bug?

Link to Stack Overflow question on possible observer's bug.

I don't know the right place to put this issue. I will happily move it to a different location if someone would like to point me to where to go or what to do?

http://stackoverflow.com/questions/34040785/polymer-1-x-obervers-bug-fix-or-workaround

2.0 Code cleanup

• remove default values for properties (this will require changes in elements that use these defaults for styling, like paper-checkbox

Allow keyBindings to be set on elements

Description

Currently keyBindings are decided by behaviors but for example for a <paper-radio-button> it is necessary to allow to directly set key-bindings on the element.

IronButtonState: code review

• pointerDown, receiveFocus... and _mouseEventRe should be proper private, and not defined in the properties block
• should import iron-control-state.html

IronControlState: code review

• IronControlState needs better docs
• [disabled] is pretty bonkers on IE (ask @kevinpschaaf for more details)
• private properties shouldn't be pre-defined in the properties block
• need to revisit the focus/blur code

iron-button-state: down handler can fail on IE due to unnecessary primary button check

The code in _eventSourceIsPrimaryInput is causing the _downHandler to fail on IE. We can simply remove this function since it is no longer needed.

Setting paper-button disabled doesn't remove it from tab sequence.

Description

Setting paper-button disabled doesn't remove it from tab sequence.

The reason seams to be in iron-control-state.html where tabIndex is set to -1. This works if it's set statically, but this doesn't work when set dynamically. What seems to work in Chrome is to remove the tabIndex attribute from the element.

Expected outcome

When the button disabled attribute is set, it should be neither clickable nor accessible by tabbing.

Actual outcome

When put on dialog, the button can be accessed by tabbing, ripple works, can close the dialog.

Live Demo

https://jsbin.com/quwadiwula/edit?html,css,js,output

Steps to reproduce

In the demo:

1. When dialog opens, click on the dialog.
2. When button disables, press tab
3. Press space

Browsers Affected

• Chrome (v51)

controls shouldn't change value when disabled

In 0.9/0.8, setting a control with both of the iron-behaviors to disabled = true results in the active property being set to false, which ends up changing the value of the controls which use these behaviors.

paper-radio-button, paper-checkbox, paper-toggle-button all rely on the active property to show the state of the control. The active property is changed by iron-button-state in _controlStateChanged when disabled is set to true. This happens because iron-control-state has an observer on disabled which calls _changedControlState.

The result is that if a checked checkbox (radio-button, toggle-button) is disabled, it is also unchecked. I would have to write my own helper function to handle disabled changing:

function disabledChanged(control) {
  // make sure this is called after _changedContolState
  setTimeout(function() {
    var checked = control.checked;
    control.disabled = true;
    control.checked = checked;
  });
}

But that shouldn't be necessary. The behavior of native HTML input controls is to retain the input value when the control is disabled.

Tab order problem

Description

Toggling disabled property removes an element completely from the tab order.

Expected outcome

Reverting disabled = false re-adds the element to the tab order.

Actual outcome

Reverting disabled = false leaves tabindex="-1" on the element and it prevents the children in the shadow tree from getting focus.

Live Demo

http://jsbin.com/perubocupi/edit?html,js,output

Steps to reproduce

Steps are in the demo

Browsers Affected

• [✔] Chrome
• Firefox
• Safari 9
• Safari 8
• Safari 7
• Edge
• IE 11
• IE 10

Differentiate mouse from keyboard focus

The old core-focusable mixin had this section for differentiating between mouse and keyboard focus. This is really helpful behavior that we used quite a lot on the I/O site. Reading the source of iron-button-state and iron-control-state I don't see the same behavior, is it still part of these mixins?

Click/enter on controls inside a checkable widget shouldn't check the widget

https://jsfiddle.net/u5m3zgxx/1/

In Chrome, clicking (or pressing Enter) on a <button> or <a> inside of a <label> for an <input> does not check the corresponding <input>.

Elements like paper-checkbox and paper-radio-button do not behavior this way; tapping the button will check the checkbox/radio-button.

Just using a <label> around a <paper-checkbox> instead of putting the content directly inside the <paper-checkbox>'s light DOM isn't great because the styling is different.

Uncaught TypeError: this.isLightDescendant is not a function

This line is throwing it: https://github.com/PolymerElements/iron-behaviors/blob/master/iron-control-state.html#L76

@blasten 9ffe111

I'm on polymer 1.1.3 right now.

The thing is isLightDescendant is not available until v1.1.5

@notwaldorf Polymer/polymer@1e9110a

but iron-behaviors seems to say polymer ^1.0.0 is ok?

https://github.com/PolymerElements/iron-behaviors/blob/master/bower.json#L19