I'm using dojo 1.9 inside Ibm Content Navigator and my dropdowns(dijit.form.DropDownButton) suddenly stop working after opening and closing the same screen about 15-20x. I click on the arrow and the options are not displayed. That happens with DateTextBox(dijit/form/DateTextBox) as well. And not only my screen dropdowns stop work but every single dropdown and DateTextBox in the system dont work anymore. All the other widgets are working fine. I have to refresh the page to make everything work again. Not doing anything special here.
these are 2 examples of dropdown and datetextbox
Does anyone have a clue of what is happening here ?
<div
data-dojo-attach-point="invoiceDateMisc"
data-dojo-attach-event="onChange: setCAVATCodes"
name="${id}_invoiceDateMisc" id="${id}_invoiceDateMisc"
tabindex="13"
data-dojo-type="dijit/form/DateTextBox"
constraints="{ min: '01/01/1950', max: new Date()}"
missingMessage="Invoice Date is a required field."
rangeMessage="Invoice Date must not be a future date."
required="true" >
</div>
<div data-dojo-attach-point="dbCrMisc"
name="${id}_dbCrMisc"
id="${id}_dbCrMisc"
data-dojo-type="ecm.widget.Select"
tabindex="14" >
</div>
It turned out there were some no modal dialogs where I show error/warning messages to users that were not being properly closed, just hidden, so after some time of system usage, it breaks the dropdowns and calendars for some unknow reason. Really tought one, no error messages, nothing on console, not a clue and I still dont know why it happened. And my attempt to fix this was just a guess, a feeling, knowing a bit more of Dojo behavior.
Related
I am trying to set up a QSelect driven by user input in order to achieve an "autocomplete" behavior. There are a few examples on the official documentation and they make use of the #filter callback.
I have currently two problems:
Whenever I click outside of the input field the input text is lost and the popup disappears.
If I click on the input the current text remains, but the pop is hidden until I click on it again.
For the latter issue, one workaround is to force the popup to show upon click:
<q-select
ref="input"
...
#click.native.prevent="onClick"
>
...
onClick(){
if( this.searchFilter.length > 0){
this.$refs.input.showPopup()
}
}
However, the inconvenience is that the popup still shortly disappears for a short while before showing again. I've also tried using #click.native.stop instead of #click.native.prevent to no avail.
As for issue number 1 I haven't even found a workaround yet.
Here is a related issue, though the popup disappearing was a wanted behavior in his case.
I set up a basic Pen to illustrate the issue. Try clicking on the input or outside the input at the same height.
The trick was to use #click.capture.native and then conditionally stop the propagation inside the callback function via event.stopImmediatePropagation() See it working here
We have been having a very strange problem in a vue-js (#vue-cli, Build version) application. There was a button in App.vue that had an onclick
<button #click="goIRList" id="irlistBtn">IR List</button>
that was working for fine for some users, every time, and not others. For the others, I checked (with alerts) that the goIRList code was not reached at all. These others had this issue with any browser we tried. They did not have the issue when Vue+Developer Tools was open - making it harder for me to debug it.
Instead of the goIRList code, these users got a page with just the error message
Cannot GET /menu.csp
That was especially perplexing, because menu.csp is code from a completely different system, though one also associated with the same computer. It is never referenced in the vue-js application.
Eventually I realized that what was happening was a submit, even though the button was not in any form on the page [I had thought that a button is only a submit type by default, if it is inside a form]. As soon as I added a type, <button type="button"...>, the issue went away completely.
Could someone explain why this was happening? And why did it work for some users? Thanks!
Update: and now the problem is back, same conditions: for them and not for me. Nothing changed. I also added .prevent to the button's onclick:
<button type="button" #click.prevent="goIRList" id="irlistBtn">IR List
and no help. So maybe that wasn't the issue. Anyhow, now I'm asking for a fix as well as an explanation. Thanks!
Add a "submit" event catcher in the form, and prevent the default action.
<template>
<div id="app">
<form #submit="submit">
<input value="Tom">
<button>Submit</button>
</form>
</div>
</template>
<script>
export default {
name: "App",
methods: {
submit(e) {
e.preventDefault();
console.log("Success!");
}
}
};
</script>
And someone pointed out the answer to me. Ridiculous: those two buttons were hidden underneath a logo image that was higher up on the page. It was the image that contained the bogus link.
I never got the error, because I can't see so well, so I keep the sizing high, and the buttons were far away from the logo. Others had a more normal page sizing, and everything got smaller except for that image; the invisible margin of the image went over the buttons, and someone trying to click on the buttons triggered the link.
I set the image to resize with the page and all is well.
I have a straightforward XPage that lets a user answer a question with a simple Yes/No/NA response using radio buttons. I have restyled the radio buttons to look like a bootstrap button group to make it visually more interesting for the user. If the user chooses "Fail" then they are informed that they need to do something else - easily done with a simple partial refresh to a div further down the page.
This all works fine.
The problem I'm having is that I'd like it so that when the user selects an option, I would like to add a new class of "active" to the selected option so that it highlights in a pretty colour. But for the life of me I can't get this to work and though I'm sure it's a straight forward problem, I can no longer see the wood for the trees.
My current (abridged) iteration of the radio button code is this:
<xp:div styleClass="btn-group item-result" id="edit-result" loaded="${Question.open}">
<xp:radio text="${lbl.kwPass1}" id="itemPass"
styleClass="btn btn-pass #{(item.itemResult eq '0')?'active':''}" groupName="itemResult"
selectedValue="1">
<xp:eventHandler event="onchange" submit="true"
refreshMode="partial" refreshId="actionAlert">
<xp:this.script><![CDATA[XSP.partialRefreshPost('#{id:edit-result}');]]></xp:this.script>
</xp:eventHandler>
</xp:radio>
<!-- other radio buttons -->
</xp:div>
<!-- other page compenents -->
<xp:panel id="actionAlert">
<!-- panel content and appropriate rendered value -->
</xp:panel>
This was attempting to do a chained partial refresh on the radio button container so that the EL would evaluate and apply/remove the 'active' style based on the document datasource ('item') value. I have also tried using dojo.addClass, dojo.removeClass, XSP.partialRefreshGet and other options. I don't mind what the solution is as long as it's efficient and works. I'd prefer not to move the actionAlert panel to within the same container as the radio buttons and I can't do a full page refresh because there are other fields which will lose their values.
Some notes:
I'm not using a RadioGroup control because it outputs a table and I haven't got around to writing my own renderer for it yet. Single Radio button controls work fine for what I need them to do.
I originally tried using the full Bootstrap solution of using "data-toggle='buttons'" (source) which sorts out applying the "active" style fine but then, inevitably, prevents the partial refresh from working.
the radio button styles are clearly not Bootstrap standard
Any assistance pointers or, preferably, working solutions would be appreciated.
You need to aim your partial refresh at the div containing all your radio buttons. Give it an id, so you can address it.
Partial refresh, as the name implies, refreshes one element and its content only. So you target the element that covers all of the items you need to recompute.
Stepping away from the problem, a couple of beers and an episode of iZombie later, I realized what I was doing wrong and sorted it out. So, for posterity, here is the simple solution that I swear I tried earlier but clearly works now:
<xp:div styleClass="btn-group item-result" id="edit-result" loaded="${Question.open}">
<xp:radio text="${lbl.kwPass1}" id="itemPass" value="#{item.ItemResult}"
styleClass="btn btn-pass" groupName="itemResult" selectedValue="1">
<xp:eventHandler event="onchange" submit="true" refreshMode="partial" refreshId="actionAlert">
<xp:this.script><![CDATA[dojo.query('.item-result > .btn').removeClass('active');
dojo.query('.btn-pass').addClass('active');]]></xp:this.script>
</xp:eventHandler>
</xp:radio>
<!-- et cetera -->
The many places I was going wrong:
In my code in the question, I was calling XSP.partialRefreshPost in the CSJS script of the radio button when it should have been in the onComplete of the eventHandler. It has to be chained to another partial refresh so that it runs after it, not at the same time. I did end up getting this right - but overlooked something I'll come to in point 3.
In my original attempt to use Dojo, my first mistake was to try and target the ID of the radio button, something like:
dojo.addClass(dojo.byId('#{id:radio2}'),'active');
This actually works as expected, so long as you remember that the ID of the radio button on the XPage refers to the actual radio button control and not the label wrapping; and the label is what I wanted to style. So the class "active" was being actually being added, just not to the element I thought it was. I should have spotted this in my browser code inspector except for the third thing I got wrong:
Ironically, I sorted out the first issue, remembering to put the XSP.partialRefreshPost into the onComplete - and then didn't remove it when trying to run the Dojo.addClass(). So I didn't notice the mistake with the addClass targeting the wrong element because after it ran, the partial refresh updated the container and removed the class I had just added which made me think that nothing was working.
So now I have some neatly styled radio buttons that don't look like radio buttons and it's all managed client side without any unnecessary partial refresh trips to the server barring the one where I actually need to look stuff up from the server. And the vital lesson is - sometimes you just need to step away from a problem and come back to it with fresh eyes later on.
I have a Protractor/Jasmine E2E Automation test that is to drag and drop a couple of collapsible panels to change the order and just verify they the elements have been moved.
I'm currently running latest versions of Protractor, Jasmine, and webdrivers (tests run in IE 11)
EDIT: Found out we're using ng-dragula to perform the drag and drops. I'm assuming protractor just isn't playing nicely with this. I'll do more digging about it, but still curious to know if there's a work around.
/end edit
This function used to work, and I have since tried a handful of variations of it:
browser.actions().
mouseMove(dragFromElement).
mouseDown().
mouseMove(dropToElement).
mouseUp().
perform();
browser.actions().
dragAndDrop(dragFromElement, dropToElement).
perform();
I've also tried with .getWebElement() appended to the element tag, getting each elements location and doing a mouse click, move, drop to those locations, and trying various actionSequences instead of actions().
Basically all of the above will highlight the text of the elements like it's clicking behind the panels and does not actually grab the element and drag/drop it.
Curious to know if this is a known problem or if there's a possible solution for my issue.
What i'm working with is:
<core-drag-and-drop-panel _nghost-wod-4="">
<div class="sortable-panels" _ngcontent-wod-4="">
<div id="elementId_10" class="draggableDiv" _ngcontent-wod-4="" aria-dropeffect="move" aria-grabbed="false">
<div id="elementId_12" class="draggableDiv" _ngcontent-wod-4="" aria-dropeffect="move" aria-grabbed="false">
<div id="elementId_1" class="draggableDiv" _ngcontent-wod-4="" aria-dropeffect="move" aria-grabbed="false">
</div>
</core-drag-and-drop-panel>
I recently by accident found an issue I have with a web application I have made entirely with dojo.
I have a TabContainer and a toolbar with buttons and each button adds a Tab in the TabContainer.
Each of these new Tabs has as children, created programmatically, one or more of the following BorderContainers, ContePanes, Editors, FilteringSelects, Uploader and Buttons. I should point out that I do not have parseonLoad: true byt false and I call manually the parsers.parse when required. I should point out that in the ContentPanes in the content attribute I put also declarative filteringSelects and ValidationTexts and Uploader I hope that is not a problem.
Everything is working great in all browsers even in IE9 besides one thing in Firefox 12.
When I create many new tabs and the ScrollingTabController gets created (The left/right and dropdown arrows of the tabstrip) when I use the ScrollingTabControllerMenuButton (the down arrow at the far right) the TabContainer behaves wrongly and eventually freezes. Firebug shows weird errors when I select different tabs via this menu of the tab strip. Errors of the buttons that I have in these tabs, weird errors mentioning StackController or ScrollingTabController
[ e.g.
button is undefined
if(this._selectedTab === button.domNode){ StackController.js (line 222) ]
different each time...
This weird behavior only happens in Firefox. IE9 and Chrome do not have any issue at all!
Could anyone have an idea on what might be the problem? Is it a known bug? Is it a problem that I have many widgets in each Tab ?
It seems that it is indeed a browser specific bug and as I was told it should be fixed in the following releases
I first reported it to the dojo community and from there they reported it to the Firefox team
http://bugs.dojotoolkit.org/ticket/15496