After upgrading from Wicket 1.5 to Wicket 9, our users now may sometimes cause a Stale Page Exception by:
Duplicating a tab
Clicking a link, submitting a form, etc., in the second tab
Returning to the first tab
Trying to click a link, submit a form, etc., in the first tab
In the past, i.e. 1.5, Wicket's default behaviour on encountering a stale page exception was to recreate the original page. This gave the users a smooth and trouble-free experience, requiring just one extra click on the link or button in order to achieve their aim. They grew used to duplicating tabs, and wish to continue doing so.
Now, in Wicket 9, a stale page exception triggers a 500 error, which is seriously undesirable behaviour.
How can we return to the default behaviour that we had before? There must be a relevant setting somewhere, but I don't know where.
I would be most grateful if anyone can tell me how to change this setting. Thanks!
This problem is solved by upgrading to Wicket 9.3.0 or later.
Related
I'm trying to test changes to our website, which is a dynamic application. When making edits to certain elements, the visual editor gives a warning:
"The number of elements selected changed after the page was initially loaded. Make sure that your changes appear as expected using preview mode." I've read all the official Google documentation on this specific warning. See the layout here
I've enabled activation events, set it to optimize.activate and made sure it is being pushed to dataLayer.
When I preview in debug mode, it says the experience was applied, the activation event was triggered on 'optimize.activate' and the url matches. Yet only one of the changes have been applied. See here
When I open the console and call dataLayer, optimize.activate is right there.
I'm honestly baffled. I read here that filters on the Analytics view linked to your Optimize container can stop events 'showing up'. We use filters to IP block our staff from showing up in our Analytics data.
Any help on this would be amazing.
p.s. I'm not a developer so go easy on me :)
Ok this maybe for a couple of reasons... I've had a few instances where I can view changes in preview mode:
First of all, if you're viewing changes in incognito mode, you need to make sure the following option is switched off in your browser - Block third-party cookies. If this is switched on, then in preview mode, your browser will block the Optimize 360 cookie and your experiment will not run. (This means you will not see your changes).
Secondly, if you have Audience Targeting set, these features do not work or show in preview mode.
Thirdly, your test may not be firing on the correct event trigger. EG pageload. So make sure the correct event is attached to your AB Test. As you will be able to see the changes in edit mode, but again not in preview mode.
Your issue is likely to be point 1 or 3.
I'm adding a blocking modal (ie one that covers the screen and prevents interaction while an API call is processing) to my company's design library.
As part of that, I modified our modal so that clicking on the grey backdrop will NOT hide the blocking modal, but I want to make sure that doesn't violate accessibility guidelines. I haven't been able to find anything online about this. Does anyone know if this this violates accessibility requirements?
Short Answer
The answer is 'it depends'. Basically if the modal is not dismissable in any way it becomes a 'keyboard trap' and so would violate WCAG.
However if you structure it correctly a modal that blocks the page while an API loads is perfectly valid (and can't be dismissed while the page is loading), but there are a few things you need to do to make sure this is accessible.
1. Make sure that when this modal loads, nothing else on the page is focusable.
The biggest issue I see on most modals is that they allow focus outside of them.
You can't just stop users using the tab key as that is not how most screen reader users navigate the page (they use shortcuts for headings (h1-h6), hyperlinks etc.).
For this reason make sure your modal sits outside of your <main> and the hide your <main> and other major landmarks that contain information with aria-hidden="true" and by adding tabindex="-1" to them so nothing is focusable.
Obviously this depends on your document structure so you would need to test it, but a properly structured HTML document will work with the above method.
2. Make sure that a screen reader user knows that the page is busy and something is loading.
There are a couple of ways to do this. The best is to use an aria-live region
Adding aria-live="polite" and aria-busy="true" to the section you are updating is one way (if you are updating one part of the page).
However in your circumstances I would make a section within the modal aria-live="assertive" and not use the aria-busy (as you will be hiding all the content in step 1 so aria-busy would not be applicable).
I would then update the message every second or two for long loads (i.e. 'loading', 'still loading', 'nearly loaded' etc. Or better yet a loading percentage if your script allows.)
Once the page content has loaded, you do not need to say 'loaded' instead make sure you have a heading for the section or page that has a tabindex="-1" added on it that accurately describes the content that has just been loaded in.
Once the load completes, programatically focus this heading and the user will know that the load is complete.
3. Make sure that if the API call fails you feed something meaningful back to screen readers
When your API call fails (notice I said when, not if!) make sure your JavaScript can handle this in a graceful way.
Provide a meaningful message within your modal aria-live region that explains the problem. Try to avoid stating error codes (or keep them short, nothing worse than hearing a 16 digit string on a screen reader for an error code), but instead keep it simple such as 'resource busy, try again later' or 'no data received, please try again' etc.
Within that region I would also add one or two buttons that allow to retry / go back / navigate to a new page depending on what is appropriate for your needs.
4. For long load times, let the user know what is happening.
I covered this in point 2 but just to emphasise it, make sure you feedback to users that things are still loading if there is a long load time by updating your aria-live region.
Nothing worse that wondering if the page has loaded and the developers forgot to tell you.
5. Give the option to cancel an API call so it doesn't become a keyboard trap.
Obviously the big problem with a whole page modal is it is a 'keyboard trap'.
To ensure this isn't an issue make sure you provide a cancel button.
Make sure it is clear that this will cancel the loading of the page, but don't rely on JavaScript alone.
Instead make this a <a> styled like a button that either points to the current page or the previous page (yet again depending on your needs) and add role="button".
Then intercept this click with JavaScript so that it can function like a button.
The reason for this is that when your JavaScript fails (yet again - when, not if) the user still has a way to get to a meaningful page, thus avoiding a keyboard trap.
This is one of the few times you should use an anchor as a button, as a fallback!
By doing this you ensure that the user always has a way to escape the modal.
You may also consider allowing a user to use the Esc key to close / cancel but that is yet again down to you and your circumstances.
(a) TIMTOWTDI =. there is more than one way to do it
(b) TIOOWTDI =. there is only one way to do it
i do not know if the case for this issue is (a) or (b), above.
The follow links may apply to this discussion:
https://developer.mozilla.org/en-US/docs/DOM/window.onbeforeunload
MSDN beforeunload | onbeforeunload event
http://dev.w3.org/html5/spec-LC/history.html#unloading-documents
http://dev.w3.org/html5/spec-LC/history.html#beforeunloadevent
... Note: There are no BeforeUnloadEvent-specific initialization methods.
please note: i am not discussing SO article 276660 "How can I override the OnBeforeUnload dialog and replace it with my own? which is about the text that the end-user sees in the dialog box; i found SO article 276660 via the first reply to this discussion: suggestion: change default for are you sure that you want to navigate away from this page? from OK to Cancel
My issue with how various browsers behave is the need to prevent the end user from losing her/his typed data because she/he accidentally clicked away from a page; such a disaster can easily occur if she/he happens to press the space bar shortly after the dialog box has been displayed; "disaster" may seem like a very strong word unless you are the end user who has just lost an hour or two of typing.
i. is JavaScript the only way to prevent this?
ii. is there some way to tell the end users' browsers to make Cancel the default?
Clarification (i hope): in a Windows O/S dialog box, it is possible to tell the Windows O/S which button to highlight as the default; for example, if the message were something like "delete all of my files", a default of "OK" is a bad idea.
SO frequently saves my text as i'm composing a question; other forums do not do the same.
i'm guessing that if my laptop were to crash as i'm writing this message then SO would give me some way to recover close to the point where i am at this moment.
Will someone please tell me whether there are one or more ways with regards to browsers, and, if there are, where to find more information?
imho, setting the default dialog box button to "OK" is far too dangerous because accidentally hitting the space bar could cause a lot of grief.
Thank you.
this is insanely annoying problem:
AS3 full screen application based on ADOBE FLEX 4, text field. User types something in text field, and then starts clicking backspace many many times to remove what he just wrote, and for some reason, instead of removing characters from text field it tells browser to GO BACK and user navigates away. Why?! Please, please help, this is so terrible. My users are losing important unsaved this is data while using my application!
i am using safari browser
PLEASE HELP.
Wow, this is terrible, I am so irritated, it happens every single time
It is possible that the focus is lost from your text field when hitting the backspace multiple times (check if you are firing some events on the text field that may cause this), which causes the main window to take focus and trigger 'Back' on the browser.
The root of the problem is that the browser carries out keyboard shortcuts REGARDLESS of the flash app having the focus or not. From what I heard this problem does not exist on Safari's for Mac, only Safari for Windows.
I would check to see what browser you are in and then create a popup saying you this app does NOT work on Safari browser ON windows.
Scratching head*
Well maybe if HAD to solve this, I would use the ExternalInterface to interact with Safari or javascript to PREVENT the history back button from getting applied. So it won't go back to an old page. That is what I would look into.
I am porting an ASP.NET application from 3.5SP1 to 4.0. The application works perfectly in 3.5SP1. In 4.0, I am seeing a difference in UpdatePanel behavior.
We have a simple user control with a testbox, a button, and some text. The user control lives inside an UpdatePanel with UpdateMode="Conditional" and ChildAsTriggers="true".
Users type into the textbox and click the button. We do a search. If we find something, content elsewhere on the page is updated - this works great. If we don't find it, we change the text in the user control. That change never appears.
So I know the button and logic is working. The user control does not own the UpdatePanel it lives in, and it would be nice if it didn't have to. But even though the button is raising an event back to the server, the update panel content is not updating.
Has anyone seen this?
My problem turned out to be 4.0's new client-ID mechanism. Check out the new features here.
4.0 defaults to 'Inherit' while 'autoID' is the 'old' behavior. By adding this to the web.config pages element:
clientIDMode="AutoID"
my problem went away. I'm not wild about forcing backward-compatible behavior but until I can sort thru all the control relationhips this will have to do.