Win a copy of Svelte and Sapper in Action this week in the JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Bear Bibeault
  • Junilu Lacar
Sheriffs:
  • Jeanne Boyarsky
  • Tim Cooke
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • salvin francis
  • Frits Walraven
Bartenders:
  • Scott Selikoff
  • Piet Souris
  • Carey Brown

Zoom Causes Eratic Behavior

 
Ranch Hand
Posts: 34
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My application uses JSP pages running under Tomcat. It's been running flawlessly for many years. I just discovered a strange error that occurs when I zoom in on a page that has been displayed using JSP. After a page is displayed, if I zoom in using the browser's zoom controls and then click on an icon or a text box, the program gets kicked back to the previous screen (the one that called the current display). I realize that there is not enough information here for anyone to diagnose my problem, but I don't even know where to start looking. I tried searching this forum on the word "zoom" but didn't find anything useful. Would somebody please give me a general idea of where to start looking to find the source of this error? Thank you very much.

Jim
 
Marshal
Posts: 67451
173
Mac Mac OS X IntelliJ IDE jQuery Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It's very likely not anything to do with the JSP-ness of the page. JSP executes on the server and sends the resulting HTML page to the browser. The fact that it was generated by a JSP is irrelevant at that point.

Zoom operates at the browser level on the HTML page that it got sent. So the problem has to be with the interaction of the browser with the HTML; not anything in the JSP.

Perhaps you could give further details regarding:

if I zoom in using the browser's zoom controls and then click on an icon or a text box, the program gets kicked back to the previous screen (the one that called the current display).


So you are getting a back action? As if the back button had been pressed? Does the URL revert to that of the previous page?
 
Marshal
Posts: 3181
466
Android Eclipse IDE TypeScript Redhat MicroProfile Quarkus Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Does this occur with just one type of browser, or different ones?

How are you zooming -- keysequence, key+mousewheel, menu selection? Same problem with each method?

Only a problem with zooming-in, or with zooming-out as well? What if you zoom, and then restore to 100%?

Have you tried using the browser's developer/debugging tools?
 
Jim Borland
Ranch Hand
Posts: 34
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you very much for two quick replies. Yes, when the error occurs it is as if I hit the back button. And, it has occurred with several different browsers. First time I noticed this was on an iPad (using fingers to zoom) and then I tried it on my Windows desktop by using the browser's zoom command with the same sad result.

Your question about if the URL reverts to that of the previous page was a good clue. This program also uses the Struts framework and the first URL is formatted by Struts. If I go to the next step so that the JSP file's name is in the URL then the problem doesn't occur. I'm looking at the Struts config stuff and this may be a situation where the "failure" option is being called which causes the previous screen (same as back button) to be displayed.

As with much troubleshooting, I am flailing about in crazy fashion searching for ideas while trying to figure out what is happening. You've given me some good help here. Thanks!
 
Jim Borland
Ranch Hand
Posts: 34
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I've done more investigation and realize the problem is caused by Struts (my application uses Struts One running under Tomcat). The situation occurs when I zoom in or out on the first page after a login. This is the first JSP page displayed after being authenticated for login. If I then perform a zoom command (zoom in or zoom out) I'm immediately bounced back to the page that requested username and password.

I have discovered that after a zoom-gone-bad I am being sent to the page called out as "input" in the login's "action" section of struts-config.xml. My understanding is that "input" is the path to which control should be returned if the form-bean returns a validation error. Since I have already successfully been validated for login, why do I now get a validation error when the browser performs a zoom?

 
Bartender
Posts: 9615
16
Mac OS X Linux Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I cannot reproduce this behavior with Struts 1. I tried a basic app of my own as well as the Struts Mailreader using both Firefox on a desktop and Safari on an iPhone. Zooming in or out works fine. No extra calls to the server to reload the page or getting logged out.

Jim Borland wrote:I've done more investigation and realize the problem is caused by Struts (my application uses Struts One running under Tomcat).



I'm not sure how this would be "caused" by Struts. Struts is an implementation of the front controller pattern using plain old JEE. If the problem occurs with Struts, I'd expect it would happen with pretty much every other web application.
Do you have any code on the page you zoom in on? Perhaps some Javascript that gets called by load, focus or blur event handlers?
 
Jim Borland
Ranch Hand
Posts: 34
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you very much for your reply. Yes, I agree that the problem is probably not caused by Struts, but it is a player right at the core of my dilemma. Here is a more thorough explanation of my situation.

From struts-config.xml (Struts One)



login.jsp is displayed to receive the username and password. Clicking "Login" there causes a user to be authenticated which brings up "mainMenu.jsp" (opening screen after login). At this time the URL at the top of the pages shows "login.big" instead of the filename "mainMenu.jsp."

At this point, if I do a zoom I am immediately kicked back to the login.jsp screen. Note from the action mapping that there are two ways this can happen: (a) forward name = "failure" or (b) input="/login.jsp." I tested these both by substituting a different filename for each in struts-config.xml and learned that it is the "input" path that is followed after a crash. Knowing that "input" is the path to which control should be returned if the form-bean returns a validation error, why is it doing that (at this point I had already been validated)?

I don't think the page I zoom in on (mainMenu.jsp) is the problem and here's why. When running my program, if I first advance to the place where "mainMenu.jsp" shows up in the URL instead of "login.big," everything works great. I can zoom to my heart's content. The problem only occurs immediately after login calls mainMenu.jsp, when "login.big" appears in the URL.

The problem appears to happen while Struts is still in control (login.big appears in the URL bar). Yet, the JSP file works fine when it's name appears in the URL. So, if the JSP file is okay and Struts isn't causing the problem, then why is this happening?

Thanks again for helping me with this problem.
 
Ron McLeod
Marshal
Posts: 3181
466
Android Eclipse IDE TypeScript Redhat MicroProfile Quarkus Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Maybe you can learn something by examining the network traffic between the browser and the server using something like tcpdump or wireshark.
 
Jim Borland
Ranch Hand
Posts: 34
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for the suggestion. I will give that a try.
 
Joe Ess
Bartender
Posts: 9615
16
Mac OS X Linux Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Jim Borland wrote:
The problem appears to happen while Struts is still in control (login.big appears in the URL bar).



Struts is not "in control" at this point. As I said before, Struts is a "front controller". It determines what resource is returned for a request. If a valid login is submitted with the request to "login.big", Struts returns mainMenu.jsp. If an invalid login is submitted, Struts returns the login.jsp (mapped as the "input" action parameter). Once the resource is returned to the browser, the browser is "in control" until another request is submitted to Struts.

Jim Borland wrote:
Yet, the JSP file works fine when it's name appears in the URL. So, if the JSP file is okay and Struts isn't causing the problem, then why is this happening?



If the main menu JSP's URL is in the browser's address field and the page is reloaded by the browser, it will redisplay the main menu JSP. If the login.big URL is in the field and the page (meaning the main menu) is reloaded, the browser will request login.big. This request will be mapped to Struts, which will process the request and presumably find that the request doesn't have login parameters and return a validation error, the result of which would be the login page.
This is why I asked you if you have Javascript on your menu page. There's got to be something on that page that triggers the page to be reloaded when the user performs a zoom.
The easiest way to fix this may be to add a redirect parameter to the forward. This would change the URL in the browser from the login URL and any page reload would simply reload the menu.
 
Jim Borland
Ranch Hand
Posts: 34
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Joe,

Thank you for another thoughtful and very understandable response. I just did a reload when login.big was in the URL field and, sure enough, it brought up the JSP file mapped as the "input" action parameter. So, I now understand that Struts is not in control when login.big is in the URL field. Thanks for clearing that up.

This is why I asked you if you have Javascript on your menu page. There's got to be something on that page that triggers the page to be reloaded when the user performs a zoom.



This apparently is the key to my problem and I will take a closer look at that file. It does contain a bunch of Javascript although a search for "load, focus or blur event handlers" (quote from your first reply) yielded nothing. This is old legacy code built by someone else and there are several calls to which will require me to examine some additional files.

Your suggestion

The easiest way to fix this may be to add a redirect parameter to the forward. This would change the URL in the browser from the login URL and any page reload would simply reload the menu.



may be the obvious solution here. Thanks for that!

Thank you so much for explaining these things to me. I now know where the problem lies and, of course, I can't begin to fix an error until I know where it is. Thanks again!

Jim
 
Jim Borland
Ranch Hand
Posts: 34
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
To close out this issue, I have solved my problem. In the Javascript files I found some code that instructs the browser to reload the page if the user happens to resize the window. After poking around with Google for a bit I found a page that states the reason for doing this is because "absolutely positioned elements get messed up when the browser window is resized." The menu in my page uses absolutely positioned elements so that explains why this code is present.

I created a redirect page for the forward action parameter that calls mainMenu.jsp, and this causes mainMenu.jsp, instead of login.big, to appear in the URL field immediately after login. So far it seems to work the way it should.

Once again, thank you very much to all of you that helped me with this dilemma. I am very grateful!
 
Jim Borland
Ranch Hand
Posts: 34
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Correction to above: My first attempt was to create a separate JSP page for use by "forward" and have that page call mainMenu.jsp. Then I did a little more reading and did this to my code in struts-config.xml



Works great! There's always more to learn!
 
We don't have time for this. We've gotta save the moon! Or check this out:
the value of filler advertising in 2020
https://coderanch.com/t/730886/filler-advertising
    Bookmark Topic Watch Topic
  • New Topic