Screen focus not starting at top of page.
Problem: I have a few screens that when launched focus is immediately shifted to an element in the middle of the page and the user has to scroll back up. This happens in Chrome and IE. The effect is much more dramatic in Chrome.
Example and debugging efforts: Once such section contains two expandable grid repeats. I've scoured every property of every cell and I see nothing to do with setting focus besides the click and key events. I tried removing all these events and it had no effect.
It seems to have something to do with these two grids. I can remove one or the other and the problem persists but when I remove both the problem goes away.
Any ideas on how to stop this behavior? We want all screens to always start at the top of the page.
***Updated by moderator: Lochan to close post***
This post has been archived for educational purposes. Contents and links will no longer be updated. If you have the same/similar question, please write a new post.
Accepted Solution
SkillStorm
US
Thanks for that but I'm afraid that's too invasive. We'll just deal with it for the few screens that do this. Or we may decide to include the dummy text box and set it to never be visible and to run on client as mentioned earlier. I'll consider this as solved as it's going to get. Thanks!
Pegasystems Inc.
CA
Hi Hermy,
Can you let us know what version of Pega you are seeing this with? Any more details about the grids as well, and the screen. How many sections is it made up of, are there any defer-loaded sections?
Thanks,
Ben
Pegasystems Inc.
IN
could you please try adding an (dummy) input text box at the top of the screen & share your observations...Thank you!
- If works we shall try configuring control 'pxhidden' to the input field.
Pegasystems Inc.
US
Hi Hermy!
Pega has a feature that will set the focus on the first actionable input on the screen, which is useful for speeding up data entry (the user can start typing immediately) but can also cause this problem when the first field happens to be far down the screen. It also has some accessibility implications by stealing focus which can be jarring for a screenreader.
Phani's suggestion above will let us know if this "auto-focus" is the culprit so we can override it if necessary.
SkillStorm
US
Ben Baril, we're on 7.1.6.
Phani Sahukaru, adding a text box makes the issue go away and no scrolling happens.
Mark Hurd , fancy meeting you here!
I've simplified the screen as far as I could and still get the problem. I deleted all other elements from the section and only one grid remains. The grid rows and columns were entirely deleted as were all action sets and footer cells (header cells are already turned off) and I turned off row editing. There are still two rows as the list it's iterating over is still present. To the best of my knowledge there are no actionable elements in this section. In Chrome the screen is scolled to half-way down the header of the column of the grid. In IE it scrolls down just below the buttons in pyCaseHeader.
SkillStorm
US
I just tried setting the dummy text box to never be visible and to run on client and that fixes the issue. This is not a desireable solution but it gives us a last ditch option if nothing else more desireable works.
Pegasystems Inc.
IN
could you also please try adding a Label layout in hidden mode associated with pxHidden' control just above the grid to get default focus...
SkillStorm
US
I'm not sure I understand the instruction but I added a dynamic layout with a pxHidden control. I set it up the same way as the text box (no property reference, visibility to If not blank, run on client). This does not fix the issue.
Just to clairfy, for the original problem focus is not going to anything, it just scrolls the page midway down.
Pegasystems Inc.
US
Hermy Reynolds wrote:
Just to clairfy, for the original problem focus is not going to anything, it just scrolls the page midway down.
It is possible that Pega is setting the focus to something but not showing the outline. I've run into that problem occasionally with headings, radio buttons, and occasionally grids. In these cases you can adjust CSS to restore the focus outline globally which should give you a better indicator.
SkillStorm
US
In Chrome it goes past the heading so I doubt it's that. There are no focusable elements in the grid (I deleted the cells to test this) and there's nothing else in the section so there's nothing I can tell that can receive focus.
Where would I make the change in the CSS? I looked at the CSS referenced in our Skin rule but don't know what to change. We are using only these OOTB rules:
py-enduser71-workarea-overrides
py-portal-stages
py-tables-overrides
pyscreenflow71
py-responsive-overrides
py-case-manager-header-overrides
Pegasystems Inc.
US
In one of those OOTB rules add the following CSS selector:
*:focus {
display: block !important;
border: 5px solid red !important;
outline: 5px solid red !important;
}
This is purely for temporary debugging and will make it fairly obvious if something invisible is receiving focus on page load. If you don't see anything with a big red outline, then I'd say it's safe to consider this avenue of investigation closed.
SkillStorm
US
Aha. The grid is using pagination. When there are enough items to cause the pagination control to show up then focus goes there. When there are few items in the list and the pagination controls are not present then focus is going to something in pyCaseContent in the Overview area at the bottom.
Know of any elegant way to prevent both of these?
Pegasystems Inc.
US
Save a copy of UserWorkForm (if you haven't extended it already) and add the following:
<script>
pega.u.d.focusFirstElement = function() {
return;
};
</script>
This will intercept the function found in pzpega_ui_doc_focus, which is part of the public API.
I would highly encourage you to keep an eye out for any unintended consequences, as this will prevent the OOTB function from ever being executed in your application. By keeping it in UserWorkForm it will be easy to back out if needed.
Accepted Solution
SkillStorm
US
Thanks for that but I'm afraid that's too invasive. We'll just deal with it for the few screens that do this. Or we may decide to include the dummy text box and set it to never be visible and to run on client as mentioned earlier. I'll consider this as solved as it's going to get. Thanks!
Pegasystems Inc.
CA
Hermy Reynolds I understand you figured out what was grabbing the focus, can you elaborate on what it was? I understand it was the pagination control, but is that just the numbers (1, 2, 3...) or was there an input box?
If it's just the numbers, and no legitimate input box that is getting control, I would not expect this behavior.
Pegasystems Inc.
AU
I used this to acheive the expected result
$(document).ready(function(){ $('html, body', window.parent.document).animate({scrollTop:0}, 0); })
This was happening because the URL wasn't actually refreshing, the inner IFRAME was, so the browser window remains at the bottom of the page.
Placing this code in document.ready forces the parent window to scroll top when the inner iframe loads.
note : Having the scrolltop inside the animate function forces more cross browser compatibility, and no need to adjust css overflow settings.