A customer has a number of XPages applications that have a jQuery Mobile user interface for use on iPads. They have been working fine for a long time. There have been no application code changes, but recently users are reporting strange behaviour in the user interface across a number of the applications.
This seems to be related to multi-value fields where JQM shows a long list of values in an overlay. When then selecting a second multi-value field the pop-up box is being displayed but then immediately replaced with the overlay for the first field but without any values.
The Domino server is 8.5.3 FP4 and the administrators tell me there have been no environment and security changes recently.
In addition to the above I am also seeing the following errors occurring :-
16/12/15 15:54: Exception Thrown
com.ibm.xsp.acl.NoAccessSignal
at com.ibm.domino.xsp.module.nsf.NotesContext.checkAccess(NotesContext.java:1631)
at com.ibm.domino.xsp.module.nsf.NotesContext.serverProcessSignedResource(NotesContext.java:975)
at com.ibm.domino.xsp.module.nsf.NotesContext.setSignerSessionRights(NotesContext.java:946)
at com.ibm.domino.xsp.module.nsf.ModuleClassLoader$DynamicClassLoader.loadClass(ModuleClassLoader.java:349)
at java.lang.ClassLoader.loadClass(ClassLoader.java:626)
at com.ibm.domino.xsp.module.nsf.ModuleClassLoader.loadClass(ModuleClassLoader.java:171)
at java.lang.ClassLoader.loadClass(ClassLoader.java:626)
at com.ibm.designer.runtime.Application.loadClass(Application.java:708)
at com.ibm.xsp.library.ApplicationFacesClassLoader.loadClass(ApplicationFacesClassLoader.java:54)
at com.ibm.xsp.page.compiled.CompiledPageDriver.getClassForPageName(CompiledPageDriver.java:169)
at com.ibm.xsp.page.compiled.CompiledPageDriver.loadPage(CompiledPageDriver.java:61)
at com.ibm.xsp.application.ViewHandlerExImpl._createViewRoot(ViewHandlerExImpl.java:489)
at com.ibm.xsp.application.ViewHandlerExImpl.createViewRoot(ViewHandlerExImpl.java:557)
at com.ibm.xsp.application.ViewHandlerExImpl.doCreateView(ViewHandlerExImpl.java:141)
at com.ibm.xsp.application.ViewHandlerEx.createView(ViewHandlerEx.java:90)
at com.ibm.xsp.webapp.FacesServlet.serviceView(FacesServlet.java:238)
at com.ibm.xsp.webapp.FacesServletEx.serviceView(FacesServletEx.java:204)
at com.ibm.xsp.webapp.FacesServlet.service(FacesServlet.java:160)
at com.ibm.xsp.webapp.FacesServletEx.service(FacesServletEx.java:138)
at com.ibm.xsp.webapp.DesignerFacesServlet.service(DesignerFacesServlet.java:103)
at com.ibm.designer.runtime.domino.adapter.ComponentModule.invokeServlet(ComponentModule.java:583)
at com.ibm.domino.xsp.module.nsf.NSFComponentModule.invokeServlet(NSFComponentModule.java:1281)
at com.ibm.designer.runtime.domino.adapter.ComponentModule$AdapterInvoker.invokeServlet(ComponentModule.java:860)
at com.ibm.designer.runtime.domino.adapter.ComponentModule$ServletInvoker.doService(ComponentModule.java:803)
at com.ibm.designer.runtime.domino.adapter.ComponentModule.doService(ComponentModule.java:572)
at com.ibm.domino.xsp.module.nsf.NSFComponentModule.doService(NSFComponentModule.java:1265)
at com.ibm.domino.xsp.module.nsf.NSFService.doServiceInternal(NSFService.java:658)
at com.ibm.domino.xsp.module.nsf.NSFService.doService(NSFService.java:481)
at com.ibm.designer.runtime.domino.adapter.LCDEnvironment.doService(LCDEnvironment.java:341)
at com.ibm.designer.runtime.domino.adapter.LCDEnvironment.service(LCDEnvironment.java:297)
at com.ibm.domino.xsp.bridge.http.engine.XspCmdManager.service(XspCmdManager.java:272)
There doesn't seem to be any indication as to which application or XPage these exceptions are related to. And I do not know whether this is related to the issues being seen in the user interface of the various applications.
Can anyone shed any light on this exception or what I should be looking for?
What jumps out are these lines:
at com.ibm.domino.xsp.module.nsf.NotesContext.serverProcessSignedResource(NotesContext.java:975)
at com.ibm.domino.xsp.module.nsf.NotesContext.setSignerSessionRights(NotesContext.java:946)
I don't know which application is causing the problem, but it looks it may be having a problem assigning signer rights. It may be worth checking for multiple signers of design elements.
The com.ibm.xsp.acl.NoAccessSignal exception is thrown when an anonymous user tries to access a protected XPages resource. So this exception has nothing to do with the strange behaviour that you are experiencing.
Related
I've searched for this specific issue here on StackOverflow and the various Apple/WebKit bug reporting systems but have yet to find it specifically cited (which just doesn't seem possible).
The problem:
On our payment page we have various form fields (inputs & selects). For PCI/security purposes we have an iframe that serves the credit card number field (the iframe only has that one field - nothing else).
The issue is that for just iOS users, they sometimes cannot put the focus on the credit card number field. There appears to be 2 different, but related iOS webkit bugs. See the UPDATE below.
If they simply navigate down from one field to another, it usually works. But if they bounce around fields, they can get into the scenario where try-as-they-might they cannot get the focus into the credit card number field it doesn't look like the credit card field gets the focus (appears to be a rendering issue).
Initially we thought maybe there was JS or some invisible DIV getting into the way, but I eventually was able to create an HTML-only example to recreate the problem. (Instructions on how to recreate the issue are on the example page.) Linking to codepen requires I include some code:
<iframe src="iframe.html"></iframe>
I've consistently been able to recreate this issue on iOS 10-12 devices (an iOS 9 device didn't seem to have the problem).
For posterity I'm going to supply the work-around I came across in a separate, but semi-related WebKit bug. However, I was wondering if others out there had stumbled upon this problem and discovered other work-arounds.
UPDATE:
After digging in further I've discovered we're suffering from 2 separate bugs. The first is mostly as I describe above, but seems to be more of a rendering issue where iOS doesn't look like it's putting the focus on a field. However, if you go to the codepen example new example I setup and follow the steps, even when it doesn't look like the field has the focus, if you type the text will render correctly.
The second problem is less likely to happen but is more detrimental. It requires 3 criteria to trip:
The iframe's source has to be cross-origin
Parent page is attaching an event listener to either touchstart, touchmove or touchend (even as simple as an empty function call)
The iframe’s field is off-screen when a different field has focus and the keyboard is present.
The result of these 3 things is that the user cannot place focus on the iframe field at all (typing goes nowhere although document.activeElement shows the last parent page input having focus). Reestablishing the ability to get the focus in the iframe can be difficult, generally need to have a parent page input that can be focused while the iframe field is visible then the user can move their focus to the iframe field from there.
If any of the 3 criteria is changed (not cross-domain, no event listeners on those 3 touch events or the iframe is visible), then only the first – less-prohibitive – bug is present.
I will update my "answer" below with this realization as well.
Update 2: The new example I put up shows both bugs in action; the first page is Bug #1 with a link to the cross-origin Bug #2 example.
Problem is resolved in my environment by adding #Ryan L's suggestion document.addEventListener('touchstart', {}); in the IFrame.
This is good as it's very simple to add and is specific to the IFrame, not affecting the container page.
Problem description: cannot 'touch' (select, edit) another form field on Safari running on iDevices (phone & pad) running iOS 12. This only happens on pages in an IFrame where the container page has added some touch events. Very obscure set of conditions that are difficult to debug.
I believe I have found a fix for this frustrating little bug, and like most bugs it's a super simple fix.
All that needs to be done is to apply a the following css to the input within the iframe.
input:hover {
cursor: text
}
Here's an updated example: https://codepen.io/ryanoutloud/project/full/AEKGjj
Now as to the bug itself, the focus is actually on the intended field and any entry from the keyboard will be registered properly. Once typing begins the caret jumps into proper position. The
issue I found with the ontouchstart="" solution is that it simply removes the caret from view entirely once focus is placed on a field.
Here's the work-around I stumbled upon: add ontouchstart="" to each of the form input elements (probably selects too).
This came from one of the work-arounds provided on this WebKit bug related to outer page click events not dispatching properly to an iframe (in the context of zooming).
I have not pushed this to production yet, but initial tests seem to indicate this works. I did have to put this on both the parent & iframe form elements to fully fix the problem. I'll probably leverage JavaScript to attach this to the form fields without needing to add the property to each form element.
Open to any other suggestions or concerns with this approach.
this work for me
document.addEventListener('keydown', function(e) {
window.focus()
$(':focus').focus()
});
[Disclaimer: I'm not sure if this kind of question is accepted here as it is about a piece of software deployed already. Rest assured I didn't drop any confidential information. Also do tell me if I violated any rules in SO by posting this so I can take it down immediately]
I have a working Learning Management System web application and I recently received a bug report about a button not showing. After investigating, I have proved that the user was not using the web app as intended. When taking an exam, he was opening multiple tabs to exploit the feature that informs him whether the answer was correct or not. He then will use this information to eliminate the wrong answers and submit all the right answers in another tab/window.
I'm using Rails 4.2. Is there a way to prevent multi-tab browsing? I'm thinking like if a user is signed in and he attempted to open a new tab of the webapp, he should see something like "Please use one tab" and all the features/hyperlinks/buttons are disabled.
Here's a screenshot of how I proved he was using multiple tabs. Notice that there are multiple logs of the same attempt # because the current implementation allows saving a study session and resuming later (this is the part that's exploited). The opening of multiple tabs searches for the most recent attempt session and continues from there. This is also the reason why most of the sessions don't have a duration value -- the user only finishes a study session for one tab (by clicking a button that ends the study session). The system cannot compute for the duration because the other sessions don't have an end timestamp.
-
This is what a single-tab user looks like:
This is more of an application misuse issue more than a bug.
You should add protection not only from multi tab, but for multi browsers aw well, so it can't be purely FrontEnd check.
One of the solutions could be using ActionCable to check if a user has an active connection already and then act accordingly.
Another, for example, generate a GUID in JS and pass it with every answer. If its different from previous answer, it means user opened a new window.
But of course the solution would depend on your current architecture, without knowing how do you currently organise client-server communication it's hard to give exact and optimal solution.
I found an answer here. I just placed this js in the application view to prevent any extra instance of the website.
Thanks for everyone who pitched in.
We've noticed a very strange behavior change on our website (asp.net MVC) starting early morning (GMT) on the 12'th of January this year (2018).
Http POSTs from the site started firing twice (unconfirmed, but we suspect sometimes more than twice), and scouring high and low we couldn't find that we'd changed anything.
One of the few things we dynamically load is Google Analytics (specifically Google Tag Manager), and in the course of trial-and-error we tried disabling everything external (which made the phenomenon disappear) and then re-enabling them one-by-one, once we came to re-enabling GA the problem re-appeared.
We also tried removing everything except GA and the problem persisted.
When searching we can't find that anything has been updated in GA, so it's very unclear why it suddenly started, and we have also been unable to find anyone else reporting the same problem (either historically or presently).
Our current best guess is that one of GA's dependencies have updated, and either it contains a bug, or it's exposing an already existing fault in our code.
Has anyone else noticed the same problem? Anyone find something in their code that caused the strange behavior of GA?
I found the error, it was caused by two erroneously set up triggers.
Both triggers were form submit type, and both had double activators, one "Activate trigger when all conditions are met" and one "Activate trigger on specific forms".
The problem was that both "all conditions" activators were set to "url matches regular expression .*", where as the second activator for both targeted a correct Form Path for each respectively.
Whoever set it up must have assumed that Google Tag Manager was using a logical "and" between the two activators (not an unrealistic assumption), but based on my testing at least it seems that the trigger activates on either activator matching.
I couldn't see any reason for the first regex match towards ".*", so the fix was to simply supply a unique url expression for each trigger.
No explanation yet as to why it suddenly became a problem, because the configuration has been wrong for a couple of months at least.
P.S. For whatever reason our GTM is not in English, so take my quoted names on fields/etc with a grain of salt as they are translated.
Update
The website uses ajax to post the forms, the combination of that and the "Await tags" flag on the triggers are looking as likely sources of why the combined conditions were not acting as expected.
Which means a non-announced performance-update to GTM regarding "Await tags" could have been the catalyst which caused the problem to start occuring with alarming frequency.
I am running into weird problems when using window scope in IceFaces 3.3. When I put debug statements on constructor and destroy method (using pre-destroy annotation), I am seeing that the same bean is being created and destroyed and re-created when a single user navigates between pages. I checked the access logs on the tomcat server and it shows that the user is using a compatible browser like IE8 and is not opening any new tabs other than navigating between the pages.
What is the lifecycle of a window scoped bean. What triggers a window scope bean to be destroyed?
This behavior does not happen consistently on the same browsers. It happens for some users using IE8 while not others. But most of the cases where the bean is re-created seem to be the cases where the user is behind some kind of proxy. Would the proxy be causing such a behavior? but then again the users session remains valid i.e. the session which keep tracks the name of the user etc., stays the same between pages.
How can this behavior be solved. Is window scope unreliable?
Yes, it's unreliable and perhaps doesn't serve the purpose of window scoping. You need to implement your own custom scope and not the icefaces predefined #{window}. The class org.icefaces.application.WindowScopeManager should give you some hints as to why you are seeing the behavior.
I am working on an ASP.NET 2.0 web solution which currently runs en-GB and zh-HK languages as the 2 current languages for the site. Others will be added at a later date.
One of the requirements is that the user can choose to override the language displayed to another language. Therefore users in Hong Kong can view the site in English and vice versa.
My 2 resource files are
Resources.resx (for English - default translations)
Resources.zh-HK.resx (for Chinese)
The site performs this logic
Load user details
Check if user has overridden the preferred language
If they have, set the Thread.CurrentThread.CurrentUICulture to this language.
If they haven't, use the browsers default.
This is implemented in the following code:
//This method is written in a base page, which all pages in the site derive from
protected override void InitializeCulture()
{
User user = /*Load custom user object...*/;
string threadLanguage = Thread.CurrentThread.CurrentUICulture.IetfLanguageTag;
//If the browser is using a different language,
//but the has chosen a preferred language,
//change the CurrentUICulture over.
if (!threadLanguage.Equals(user.Language, StringComparison.OrdinalIgnoreCase))
{
CultureInfo userLanguageCulture = CultureInfo.CreateSpecificCulture(user.Language);
Thread.CurrentThread.CurrentUICulture = userLanguageCulture;
}
base.InitializeCulture();
}
I have also configured the web.config to pick up the uiCulture automatically with
<globalization uiCulture="auto"/>
For some very very odd reason, some users (even en-GB users) are finding the language is switching over the zh-HK for no reason whatsoever - sometimes between pages! I have added some debugging code to these pages which should reveal more information in the coming days. All it has revealed so far is that users are not necessarily from zh-HK, some are from zh-CN or zh-TW. Although this might help, because en-GB users are seeing zh-HK I think it is just a red herring.
What I have noticed is that the switch over occurs on page content (those inheriting from the base page, which the IntializeCulture() method exists). The custom user controls I have written do not experience this problem and appear in the correct language configured by the user. Therefore a page would have combinations of both English and Chinese content - eek!
Can anyone give guidance as to if I am coding this correctly, or an alternative way of approaching the requirements.
Thanks in advance,
Dominic
P.S. This is an intermittent problem and not a permanent. There seems to be no common action that replicates this issue. It just - happens.
P.P.S Here is an image of the problem in action:
Update 23 Sep 09:
After trying to change it to Page.Culture, I am still having more intermittent problems.
I have a couple of ideas at why this could possibly be occurring, but am unable to justify my 'hypothesis':
We are using IIS 5.0 Isolation Mode, meaning only aspnet_wp.exe is running and not w3wp.exe for each IIS instance.
Reporting Services is also running on the server, generating reports for Hong Kong.
The fault occurs more frequently when the site was under heavy load - I assume due to large reports being generated.
Apart from that, I do not know what else could cause the problem. I would show another screenshot, but the problem is identical and did appear in the same place as the previous screenshot showed.
Update 25 Sep 09:
I think we I might have solved it. In our Web.config, there is a tag that was configured as follows:
<globalization uiCulture="auto" culture="auto"/>
After removing that, after initial testing, it has yet to turn up!
Update 13 Oct 09:
The problem has turned up again :-(
Update 26 Oct 09:
It seems that if another user of the site changes their preferred language, it affects all other users on the site! Although their preferred language is set, somehow someone else's language switch affects the other users of the site!
Shouldn't it be using Page.Culture, not Thread?
After a long, long time I finally worked out why this problem occurred.
The site started off as a frameset.asp, hosting 3 .NET frames - top, middle, bottom. What I noticed, is that .NET generated 3 sessions, and therefore any changes only affected one frame.
In a way, it doesn't completely explain why only parts of the page were working, but it has resolved quite a few issues regarding some of the odd Repsonse.Redirects we were going.
In summary, the frameset.asp, was replated with a frameset.aspx, which generates a single cookie / Session ID for all frames.