polymerelements / iron-overlay-behavior Goto Github PK

I've recently seen a problem in Chrome on both Ubuntu and Mac OSX where opening an iron-overlay throws a Javascript error:

Uncaught TypeError: Cannot read property 'toString' of null

The full stack trace looks like:

obj.addEventListener    @   polydev/vendor/zone-microtask.js:973
Gestures.add    @   polymer.html:752 
Polymer.IronOverlayBehaviorImpl._toggleListener @   iron-overlay-behavior.html:268
(anonymous function)    @   iron-overlay-behavior.html:286
arguments.(anonymous function)  @   polydev/vendor/zone-microtask.js:406
(anonymous function)    @   polydev/vendor/zone-microtask.js:98
run @   polydev/vendor/zone-microtask.js:118
zoneBoundFn @   polydev/vendor/zone-microtask.js:91

I've seen this with both iron-dropdown and several custom elements I've used that mixin iron-overlay-behavior.

In firefox or safari using iron-overlay-behavior 1.0.7+ tapping outside the element causes a type error to occur in the handleNative fn. After some investigation it seems like ev.currentTarget is not the document node with __polymerGestures attached too which should of been assigned from a call to Polymer.Gestures.add within _toggleListeners when opened. Could this possibly be something todo with event forwarding? the correct node is wrapped up in __imp** not currentTarget.

Polymer changes internal implementation of Polymer.Base.fire, so this method can no longer be called with a custom context.

Scenario:
I have used iron overlay behavior and made overlay component. I have DOM element which i show inside the overlay as content and which has a click handler. Inside click handler i have done e.stopPropagation and when i click that element overlay closes it self.

I remove the stopPropagation the overlay remains open even after clicking the element.

When using a paper-dropwdown-menu a horizontal scrollbar is added, how can i remove it?

Is there any solution to remove it with css?

#23

Maybe this is a no-op, but if you override z-index of the overlay-backdrop using:

 --iron-overlay-backdrop: { z-index: 1000; }

Wont this throw off the z-index calculations in -manager which always starts at 10?

Opening an iron overlay within another iron overlay has a few issues.

Firstly : When adding a backdrop, if you open a second overlay, the second backdrop has the wrong z-index, and when you close the second overlay, the background does not go away.

Opening the first overlay - note the backdrop z-index of 11.

Opening the second overlay. The backdrop does not have the right z-index (it's 9, when it should be higher than 11). Additionally, it does not have the 'opened' attribute.

On closing the second overlay backdrop 2 stays, and when then closing the first overlay, backdrop 1 disappears, but backdrop 2 stays on top of the page. Note how backdrop 1 (with z-index 11) has disappeared, but backdrop 2 with z-index 9 is still there.

Additionally, pressing escape with both overlays open closes both of them, when you would expect it to only close the one on top.

For our use case having overlays within a full page overlay makes sense, but it may be that they weren't designed to be layered in the first place?

When an iron-overlay-behavior element is open, changes to with-backdrop should update the backdropElement presence.

E.g.

<simple-overlay with-backdrop opened>
  Hello
</simple-overlay>
<script>
  setTimeout(function() {
    var overlay = document.querySelector('simple-overlay');
    overlay.withBackdrop = false; 
    // the backdrop element should have been closed
    console.log(overlay.backdropElement.opened); // should log false
  }, 1000);
</script>

iron-overlay-behavior triggers position calculation too early (or ready), resulting in a wrong/offsetted rendering of the element. Instead, this should be done on attached.

After installing 1.3.0, focus on iron-inputs in 'paper-dialog' stopped working. I cannot focus on any input after clicking anywhere else on the dialog or outside the dialog. Seems like this might be the breaking change a72f902 added a new listener for 'focus' but it is only handling it when having a dialog 'withBackdrop'. When I get rid of the listener the focus starts working just fine.

Focus: focus state on this page is not very visible and should be revisited.

In general, this appears to be working fine with screen reader and keyboard navigation (testing just with Chrome / Mac / VoiceOver today as I don't have corp access on my Chromebook or Win machine remotely). Upon opening one of the overlays, I am able to navigate to the text / buttons within the overlay, but I can also navigate to the other options at the top of the page while the overlay is still open.

These overlays would seem more intuitive for screen reader users if focus stayed within them until the user took an action, e.g. activated one of the buttons or pressed escape. I don't think it should be possible to navigate to any of the background content before first closing out the dialogue. What are your thoughts? Is that not your intent here?

Also, we should consider making the titles of the overlays speak as announcements once open, so the user has better context about what just opened.

aka layered

I recently updated all my modules and this error is coming up. Not sure if it is a bug or something i am doing wrong.

Uncaught TypeError: Cannot read property 'toString' of nullobj.addEventListener @ polydev/vendor/zone-microtask.js:973Gestures.add @ polymer.html:673Polymer.IronOverlayBehaviorImpl._toggleListener @ iron-overlay-behavior.html:262(anonymous function) @ iron-overlay-behavior.html:280fnNames.map.forEach.global.zone.(anonymous function).arguments.(anonymous function) @ polydev/vendor/zone-microtask.js:406(anonymous function) @ polydev/vendor/zone-microtask.js:98run @ polydev/vendor/zone-microtask.js:118zoneBoundFn @ polydev/vendor/zone-microtask.js:91

Expected

I can access the original event in iron-overlay-canceled to determine the

Actual

Not possible to access the original event

Long description

I used iron-overlay-behavior triggered by focusing/writing in an input field and wanted to avoid reopening the overlay when i focused the input again after clicking some stuff in the overlay.
(I try to implement a multiselect dropdown where the input is also used to search the options).

Only solution i found that allowed me to still use the close on click outside was to
add the original source event as detail to the iron-overlay-canceled event

(function() {

  Polymer({

    is: 'simple-overlay',

    behaviors: [
      Polymer.IronOverlayBehavior
    ],
    cancel:  function(event) {
      var cancelEvent = this.fire('iron-overlay-canceled', event, {cancelable: true});
      if (cancelEvent.defaultPrevented) {
        return;
      }

      this.opened = false;
      this._setCanceled(true);
    },
    _onCaptureClick:  function(event) {
      if (!this.noCancelOnOutsideClick &&
          this._manager.currentOverlay() === this &&
          Polymer.dom(event).path.indexOf(this) === -1) {
        this.cancel(event);
      }
    }

  });

})();

This allowed me to determine if the user clicked the input by adding a on-overlay-canceled function

<simple-overlay id="results" class="scrollable" on-iron-overlay-canceled="_checkOverlayCancle">

      _checkOverlayCancle: function (e){
        if(e.detail != null && 
          e.detail.srcElement != null &&
          e.detail.srcElement.classList.contains("tos-multiselect")){
          e.preventDefault();
          e.stopPropagation();
        }
      }

From @dsportes on June 14, 2015 12:15

I have a modal paper dialog opening a second modal paper-dialog.
This causes a loop (Maximum call stack exceed) in two different locations :
iron-overlay-manager.html line 63
paper-dialog-manager.htm line 210
I didn't find any workaround.
Regards

Copied from original issue: Polymer/polymer#1864

In here, we should pass this._callOpenedWhenReady as input
https://github.com/PolymerElements/iron-overlay-behavior/blob/master/iron-overlay-behavior.html#L166

    ready: function() {
      this._ensureSetup();
      if (this._callOpenedWhenReady) {
        this._openedChanged(this._callOpenedWhenReady);
      }
    },

ON Android with Talkback, upon opening these overlays, I receive no spoken feedback. This should speak out the title of the dialog as a spoken alert. Without seeing this visually, I have no idea that something is on the screen.

Also, once I open the Hello World overlay, I have no clear way to get out of it.

Once an overlay opens, like the scrolling one, it should steal focus. Right now, if I open it and continue swiping linearly, I just go to the next buttons and don't have access to the scrolling content.

I'd like to distinguish between a close and a cancel (from clicking outside the region).
Close happens to late, and I need to take action based on a cancel.

Firing iron-overlay-canceled would be ideal or even making canceled notify.

no-cancel-on-outside-click has no apparent effect on mobile Safari. I was unable to close overlay by tapping outside, in the backdrop area.

From @erichnascimento on October 8, 2015 0:43

When key ESC is pressed in nested dialogs, all dialogs are closed instead of the highest dialog only.

Copied from original issue: PolymerElements/paper-dialog#45

From @borismus on November 2, 2015 22:28

Regardless of whether or not this boolean value is set to true or false, the dialog can always be canceled with ESC.

Copied from original issue: Polymer/polymer#2669

Basic scenario, have an item, which within its on-tap a non-modal paper-dialog, the overlay flashes up (sometimes slow enough to see) and then closes.

Using on-click it will appear, seems the handling of on-tap causes two events.

  <paper-item id="master" on-tap="tapMasterItem">{{currentLabel}}</paper-item>
    <paper-dialog id="menuDialog" with-backdrop="false">
      <paper-dialog-scrollable>
        <paper-menu selected="{{currentValue}}">
          <template as="dataitem" is="dom-repeat" items="{{items}}">
            <paper-item id="{{getValue(dataitem)}}" >{{getLabel(dataitem)}}</paper-item>
          </template>
        </paper-menu>
      </paper-dialog-scrollable>
    </paper-dialog>

    tapMasterItem: function(){
      if(!this.$.menuDialog.opened){
        this.$.menuDialog.open();
      }
    },

If two different elements are created, element-overlay-with-backdrop and element-overlay-with-backdrop2, both implement iron-overlay-behavior and both used with-backdrop, opening one after another and closing them, one overlay closes the other one's backdrop, and one backdrop doesn't close (is orphaned).

I have a suspicion that the manager is not working as it should - the current tests only cover the case where the overlays share the same backdrop - but once we introduce a different element which does not share (the backdrop is created on register event) - there are issues with correctly attributing backdrops and closing the right one.

Currently iron-overlay-behavior calls fit on opened (_prepareRenderOpened), and resetFit on close (_finishRenderClosed).
Instead, it should only call refit on _prepareRenderOpened, since the measuring of the dimensions matters in that moment, not when the overlay gets closed.

If you open an overlay, then close it by clicking outside, the closingReason.canceled flag is set to true, all good so far. If you open the overlay again, then close it by clicking outside, the closingReason.canceled flag is set to false, and any listeners to iron-overlay-closed receive event.detail.canceled === false.

I think the problem is the cancel method in iron-overlay-behavior.html is setting opened to false before setting canceled to true. When I switched the lines within cancel, closingReason.canceled was set correctly and iron-overlay-closed listeners receive the proper canceled flag.

There is also a comma ending the first line in cancel, should probably be a semi-colon. Also wondering if this change should be made to the close method as well.

Lines in question: https://github.com/PolymerElements/iron-overlay-behavior/blob/master/iron-overlay-behavior.html#L213-L214
JSBin: http://jsbin.com/refogupana/1/edit?html,output

It would improve performance to delay _onIronResize via requestAnimationFrame. e.g.

    // properties...
    _boundOnIronResize: {
        type: Function,
        value: function() {
          return requestAnimationFrame(this._onIronResize.bind(this));
        }
      }
    //...
    listeners: {
      'iron-resize': '_boundOnIronResize'
    },
    //...
    _onIronResize: function(){
       //can be overridden
    }

Same for _renderOpened/_renderClosed

http://stackoverflow.com/questions/31199823/iron-overlay-behavior-styling-not-taking-effect

I have implemented the above component at http://polymer.zikes.me/bower_components/my-overlay/. You will see that changing the custom CSS variables do not have an effect on the backdrop.

I believe this is partly because the backdrop is created but not added to the parent component's scope. Adding the line this.scopeSubtree(this._backdrop); to the registered function of iron-overlay-behavior.html should resolve that, however the component's <style> and contents are still not copied into the parent document to apply those styles, and I do not know how to resolve that.

Looking through iron-overlay-manager.html, it looks like multiple overlays with backdrops are expected to work. It seems to be broken, though.

http://jsbin.com/taxoli/47/edit?html,output

In this example, the second overlay should have a backdrop, but the backdrop is still under the first. Looking at the source, it seems as if the backdrop is meant to move under the top-most dialog.

Other problems can occur when nesting overlays with backdrops. The backdrop is appended to the body, so it can't exist in the Z-space between the nested overlay element and its ancestor.

Sometimes the path wouldn't be on Polymer.dom(event) because it returnes a node and event is CustomeEvent, thus it would give an error and not close the dropdown on click outside. The following code fixes the issue. please add it to the file.

_onCaptureClick: function(event) {
  var ev = Polymer.dom(event);
  if (!this.noCancelOnOutsideClick &&
    this._manager.currentOverlay() === this &&
    (
    (ev.path && ev.path.indexOf(this) === -1)
    ||(ev.node
      && ev.node.path
      && ev.node.path.indexOf(this) === -1)
    )) {
    this.cancel();
  }
},

From @pensierinmusica on August 7, 2015 14:46

Hi,

If the <paper-dialog> element has the attribute modal="true", the dialog does not close when the user clicks outside of the dialog area (as it properly does instead without modal="true").

The only interaction event that seems to close the dialog is the esc key (that, btw, is not available on mobile).

Any idea when this could be fixed? Thanks!

Copied from original issue: PolymerElements/paper-dialog#27

Syntax needs to be updated to reflect this style:

Polymer.Base.fire('eventName', { ... }, { ..., node: targetNode });

iron-overlay-behavior.html (line 19)
the behavior comment starts with /** instead of
this is causing a parsing issue on firefox, resulting the page to throw and error and ruin the page.

P.S. I caught the error while using polymer iron dropdown, the issue was causing the page to fail on calling the dropdowns to close on page load.

• aria-hidden

More their problem than yours, but if someone else hits it delete lines 41-49 from iron-overlay-behavior.html for the time being.

https://bugzilla.mozilla.org/show_bug.cgi?id=1229966

https://elements.polymer-project.org/elements/iron-overlay-behavior#event-iron-overlay-closed

* @param {{canceled: (boolean|undefined)}} set to the `closingReason` attribute

Not sure exactly what this is supposed to look like. The description isn't really helpful.

I'm not sure whether the @param tag to an event should assume that the parameters are all passed in the detail object, or whether they may be added directly to the event object. (Maybe @garlicnation can help out here?)

In the first case, this should probably be:

* @param {boolean|undefined} cancelled Whether the overlay was cancelled.

In the latter case, I think it should be something like:

* @param {{canceled: (boolean|undefined)}} detail Set to the `closingReason` object.

Also, we really need to work on formatting those closure type definitions better in the output. They are fugly.

From @anthonytordillos on October 20, 2015 6:9

"the object with focus before the dialog box is opened should be saved. This will allow restoring focus to this element when the dialog box is closed."

Is this something paper-dialog-behavior can provide, or are consumers of the element required to handle it themselves?

http://www.w3.org/TR/wai-aria-practices/#modal_dialog

Copied from original issue: PolymerElements/paper-dialog-behavior#32

Currently, iron-resize gets called after iron-overlay-opened http://jsbin.com/xeyeqef/1/edit?html,console,output
Shouldn't iron-overlay-opened be called only after iron-resize instead?

On line 41 in iron-overlay-behavior.html is a <body> tag that failes in Firefox.

Console log reports

SyntaxError: unterminated comment

The output of that file is

### Backdrop

Set the `with-backdrop` attribute to display a backdrop behind the overlay. The backdrop is
appended to `<body><script type='text/javascript' id="__bs_script__">//<![CDATA[
    document.write("<script async src='/browser-sync/browser-sync-client.2.7.7.js'><\/script>".replace("HOST", location.hostname));
//]]>
//# sourceURL=http://localhost:3000/bower_components/iron-overlay-behavior/iron-overlay-behavior.html.js

http://jsbin.com/qosiqix/1/edit?html,output

iron-overlay-backdrop will rely on the event transitionend to call the method complete() after it gets closed, which will handle the removal of the backdrop from the body if necessary.

it seems that there is another problem with the #64.

I've made you a JSBin

https://jsbin.com/lapedorogo/edit?html,console,output

I don't know why, but if you use paper-dropdown-menu + paper-menu + paper-item inside a dialog (dialog and paper-dropdown-menu are differents module), when selecting an item in the paper-dropdown-menu, an event will be fired which seems to be "iron-overlay-closed"

Update : no need to select an item, clicking outside to hide the list will have the same effect

Currently when an overlay with backdrop is opened, it still allows the user to focus on elements behind the backdrop by using TAB
https://elements.polymer-project.org/elements/iron-overlay-behavior?view=demo:demo/index.html&active=Polymer.IronOverlayBehavior

Instead, the focus should be trapped within the overlay while opened
http://jsbin.com/koxoyu/3/edit?html,console,output

I am not sure I understand issue #83 and this might be the same, but I suspect not. I also think it might have been introduced in a fairly recent change - because the code was working fairly recently. However I am not 100% sure of that as I have had to adjust timings of other things to handle a problem with theming. and it is possible that that change meant there are less things for the ajax request (see below) to queue behind.

It is a timing issue in that the dialog box that is opened and closed fairly rapidly. Let me try and explain ...

When I start up my application, I check for the existence of a cookie. If it doesn't exist I put up a modal dialog box to collect user credentials. The user clicks on an OK button it doesn't close the dialog box immediately, but rather sends an ajax request to the server to check credentials. Only if it passes these credentials the server sets the cookie (with an authentication token) and the dialog closes. This all works fine.

If the cookie exists, I briefly open a modal dialog box with a spinner in it. I then send an ajax request to the server to ask it to validate the user. Assuming it does, the Ajax response causes me to close the modal dialog box again.

Until recently this all worked fine. But over the past few days I have been experiencing a complete lock up of the user interface when the second case is true (ie we make this very quick Ajax call which causes me to open and then close the dialog rapidly). Putting the debugger on things I have been able to see that the overlay is still in place after I have closed the dialog. From the debugger, it reaches the close function of iron-overlay-backdrop.html, which attempts to set the this.opened flag to false. The _onTransitionend function is not called.

The flight time of my ajax request seems to be about 6 milliseconds.

I have now added a 200 millisecond delay before closing the dialog and it started working again.

When the last overlay is closed, focus should move back to the origin element.
E.g.

• button opens overlay
• click outside overlay closes overlay

Expectation: button has focus

Here the example: Close overlay 2, overlay 1 should still be opened but instead gets closed
http://jsbin.com/xuguxa/1/edit?html,output

See PolymerElements/paper-dialog#86

From @anthonytordillos on October 20, 2015 6:11

Based on the WAI-ARIA best practices[1], it sounds like focus should wrap from the last focusable item in the dialog to first, and vice versa. As currently implemented, focus just stays on either the first or last focusable element depending on the direction of traversal.

1. http://www.w3.org/TR/wai-aria-practices/#modal_dialog

Copied from original issue: PolymerElements/paper-dialog-behavior#33

From @barakhub on August 30, 2015 4:15

paper-dialog-behavior provides modal behavior. If focus is set outside of the dialog, it's returned to somewhere within the dialog. In that case, the current focus handling should stop.

Example where this causes an issue:
http://poly-play.appspot.com/A5xo5E3I5iQ
(Follow the on-screen instructions to reproduce)

Here, if you try to tab out of the dialog, you can't (expected), but the next paper-button (outside of the dialog) is highlighted as it it has focus, since the focus event for it continued to propagate.

Copied from original issue: PolymerElements/paper-dialog-behavior#24