How to supress keys caught by iron-a11y-keys - polymer

In Polymer 1.0, I'm using iron-a11y-keys to capture the enter event on a paper-textarea so that enter keys trigger a submission event. However, after the event is captured, I'm seeing the newline character be applied to the next paper-textarea that I create, adding a superflous newline.
This didn't happen in Polymer 0.5 using the 0.5 analogous elements.
Is there any way to suppress the delegation of the keys caught by iron-a11y-keys?

I had the same issue. Fixed it by calling .preventDefault() on the "keyboardEvent" which is buried in the "keys-pressed" event like this:
onEnter: function (keyspressed) {
keyspressed.detail.keyboardEvent.preventDefault();
//do stuff
}
You can also get at it like this:
onEnter: function (keyspressed, detail) {
detail.keyboardEvent.preventDefault();
//do stuff
}

Related

mxgraph block mxevent effect

I'm trying to add a simple 'confirm to remove dialog' on my mxgraph based app, but can't keep the remove event from actually happening when I want to cancel it. So far, I'm listening to mxEvent.REMOVE_CELLS, in my simplest approach I tried something like:
graph.addListener(mxEvent.REMOVE_CELLS, (sender, evt) => {
evt.consume();
});
As far as I know, consume should keep the event from propagating, and as I understood to have effect at all, but the nodes are deleted no matter what. I even tried to undo immediatelly after the event, and still not working.
Is there even a straight forward way to keep an event from happening and apply a different logic instead
Finally, I ended up overriding mxGraph.removeCells to fire my own custom event, looks something like:
mxGraph.prototype.removeCells = function(cells, includeEdges) {
...
if (shouldntRemoveDirectly) {
this.fireEvent(new mxEventObject('beforeRemoveLoop', 'cells', cells, 'includeEdges', includeEdges));
return;
}
...
}

Stub Element Is Not Effective In The Ready Function

With Polymer 1.* and WCT, when testing my element <sp-veteran></sp-veteran> I am not able to stub out the methods ._getSpComboBox() and ._getItems() in the ready function. I get Error thrown outside of test function: this._getSpComboBox(...)._getItems is not a function.
Since it is in the ready function, I need to use the WCT api stub instead of sinon.stub since the later requires me to grab the element which I can not do before fixture().
Any suggestions?
original code:
_getSpComboBox: function() {
return Polymer.dom(this.$.veteran.root).querySelector('sp-combo-box');
},
ready: function() {
if (this.editMode) {
this._getSpComboBox()._getItems();
}
this.$.veteranNoAjax.read();
this._setStyle();
}
test:
<test-fixture id="sp-veteran">
<template>
<h2>edit veteran in edit mode</h2>
<sp-app>
<sp-toast></sp-toast>
<sp-veteran edit-mode></sp-veteran>
</sp-app>
</template>
</test-fixture>
before(() => {
replace('sp-app').with('fake-sp-app');
stub('sp-ajax', {read: ()=> entitiesMock});
const _getItems = ()=> entitiesMock;
stub('sp-veteran', {_getSpComboBox: ()=> _getItems});
Unfortunately testing ready in Polymer1 is kind of a pain, or at least I haven't found an easy way that doesn't have odd side-effects. Calling the ready method after you've attached your stubs/spies is always an option but as I mentioned it can cause some odd issues. This was alleviated in Polymer2 as ready is called by the first call of connectedCallback for your element, so you can create the element then bind your spies and manually add to trigger it, just don't forget to remove after.
In the case of DOM manipulation in a Polymer element, you should be using the attached lifecycle instead, this will solve your issue as I mentioned above for testing, but it also saves you a weird potential usage case in the future. Since ready only runs once for an instance of an element, any logic in your ready statement won't get re-run if that element is re-used later, instead if you put the logic in your attached lifecycle if that element is removed from the DOM then added again later in another location it will rerun it's logic to fetch it's new children.

How to use Polymer lifecycle hooks

I have a component that contains video. My component is nested in a dom-if and can disappear. When this happens the video (and it sound) keep playing.
Is there a way in which my component can detect that is has disappeared from the DOM? I have tried to use the 'detached' callback as described here: https://www.polymer-project.org/1.0/docs/devguide/registering-elements
Polymer({
is: 'my-component-with-video',
properties: {
// some properties
},
detached: function() {
console.log('Component detached');
// more code to stop video
},
but when my element is removed by the dom-if nothing happens, I don't see the console.log message. What am I doing wrong?
There are two scenarios possible here:
You want your element to be discarded and recreated fresh when the condition changes.
You want to keep it in the dom but freeze it.
In the first case you need to add the restamp attribute to the dom-if to make sure the template DOM is destroyed, not hidden. By default the dom-if stamps the template at first initialization and then hides it from the view if the condition becomes falsy.
In the second case, the suggestion given by Intervalia will not work, because the dom-if in "hide" mode does not detach anything from the DOM. Setting restamp attribute will make the detached callback run but then no point in pausing anything since the element will be discarded.
If you want to keep it in the DOM and freeze it's state you need to listen to dom-change event on the dom-if and run the .pause() accordingly.
No need for any workaround other than simply using your dom-if and rather than
<dom-if if="[[condietionBoolean]]">
<your-video-element id="giveanId"></your-video-element>
</dom-if>
write the if statement like below and so each time your condition changes, you check and make sure the video is paused if when you like. See below.
...
<dom-if if="[[_shouldShowVideo(conditionBoolean)]]">
<your-video-element id="giveanId"></your-video-element>
</dom-if>
...
Polymer({
is: 'my-component-with-video',
properties: {
conditionBoolean : {
type: Boolean,
},
},
_shouldShowVideo: function(conditionBoolean ) {
if (!conditionBoolean) this.$$(#yourVideoElementId).pause();
return conditionBoolean ;
}
});
In your detached function you need to get the Video Element and call .pause() on it.
You will probably also need to call .pause() when your condition changes that would cause the dom-if to remove the player.

flex setFocus on creation complete

Normally, forms and pop Ups don't have the focus set when they are just displayed. The obvious solution was to set the focus to the first input in the creation complete event of the component, so the keyboard short Cuts like tab and space start working.
The problem is that, creation complete is not the panacea, sometimes the element is not focus-able at that point, and i am not sure why that happens.
The render event would ensure the focus, but it dispatches too much for a very simple purpose.
In which point a component is always ready to be focus-able?
Edit: The component giving me trouble to get start up focus, is a TitleWindow, which can be poped in 2 ways, a Mouse click event and a keyboard event.
When the tite window is displayed by a click, the first input gets focus in the creation complete event, but when displayed by a keyboard event, it doesnt...
By now i got it working with the following code:
private function titlewindow_creationCompleteHandler(e:FlexEvent):void{
callLater( setTextInputFocus);
}
private function setTextInputFocus():void{
txtPregunta.setFocus();
}
But doubt the way is shown has anything to do with this... because, some other TitleWindow are displayed this way too and they're fine.
So what could it be?
The render event would ensure the focus, but it dispatches too much for a very simple purpose.
If this is true then why not try this:
private function titlewindow_creationCompleteHandler(e:FlexEvent):void{
var callback : Function = function(re : Event) : void {
titlewindow.removeEventHandler(RenderEvent.orsomething, callback);
setTextInputFocus();
};
titlewindow.addEventHandler(RenderEvent.orsomething, callback);
}
Might be kind of a hack since it should be focusable on creationComplete but it would probably work.

Is it possible to stop child click events propagating to parents when handled by .live()?

I have 'Back Board' on my images and content over here: http://syndex.me
So basically, you click on an image, it will overlay a info panel above the clicked content.
I want to do two things:
Click on the background of the site to fade out the currently opened info panel
Be able to click on a tag, link, or social icon within the info panel without triggering it's parent function, which is too fade out again.
I cannot use stopPropagation for the child click being superseded by the parent click as i need the click events to be handled by .live() (see documentation) This is due to the fact that posts are being dynamically loaded.
I cannot just say something like:
$("#Background").click(function(){//fade out the Info Board}
Because that is being covered by the entire post wrapper, and i can't put an event ont hat because then I'm even deeper in the dilemma of parents taking over children's events :-)
So far I'm at least able to have just one infoboard open (i.e I click on one image, then another, it will close the already opened one, and open the current one. So this part is all good:
$('.theContent:not(.clicked)').live("click", function () {
$(this).children('.postInfo').fadeIn(400);
$(".clicked").each(function() {
$(this).find('.postInfo').fadeOut(400);
$(this).removeClass('clicked');
});
$(this).addClass("clicked");
});
$('.clicked').live("click", function () {
$(".clicked").each(function() {
$(this).find('.postInfo').fadeOut(400);
$(this).removeClass('clicked');
});
});
Re .live(), .delegate() and .stopPropogation():
Since the .live() method handles events once they have propagated to the top of the document, it is not possible to stop propagation of live events. Similarly, events handled by .delegate() will propagate to the elements to which they are delegated; event handlers bound on any elements below it in the DOM tree will already have been executed by the time the delegated event handler is called. These handlers, therefore, may prevent the delegated handler from triggering by calling event.stopPropagation() or returning false.
How about simply checking whether the event actually took place on the specific element:
function activate(el) {
el.find('.postInfo').fadeIn(400);
el.addClass('clicked');
}
function deactivate(el) {
el.find('.postInfo').fadeOut(400);
el.removeClass('clicked');
}
$('.theContent:not(.clicked)').live('click', function(e) {
deactivate($('.clicked'));
activate($(this));
});
$('.clicked').live("click", function(e) {
if (! $(e.target).is('a')) {
// this should not trigger if a click occured on one of the links
deactivate($(this));
}
});
$('#ape').click(function(e) {
if ($(e.target).is('#ape')) {
deactivate($('.clicked'));
}
});
Have you thought about binding the click event when the post is dynamically loaded? This way you can use stopPropagation().
http://jsfiddle.net/rkw79/CzEj5/
If you bind the event to a parent element, it won't stop its propagation event to it's childrens.
You have two solutions, to bind an event to every children and put THERE the stop propagation call, or just test who ired the click event in the parent. I prsonaly find more elegant the second solution.
You can read something more about it here :
http://redfishmemories.blogspot.it/2014/08/jquery-prevent-event-propagation-and.html