I'm working on a Java webapplication. Something I did, perhaps the javascript, caused the back button of the browser to stop working (it actually just shows a thinking circle on the tab in chrome).
The problem seems to be only in chrome
I'm not sure exactly what to look for...
What can cause the browser back button not to work?
This is an open bug on Chrome. It may not have anything to do with your application: http://www.google.com/support/forum/p/Chrome/thread?tid=1893e974f696f250&hl=en
Edit:
Here's the quick link to the actual reported bug.
Are you using the location.replace method anywhere? If you're talking in general and not just in Chrome, it's the only thing I can think of that would cause the back button not to work.
See the first point here.
Other than that, and especially if it just happens on Chrome, a browser bug seems much more likely.
Sounds like it could be a server side problem. Make sure you don't have any infinite loops and limit the runtime of your script.
Related
Ok, so this is a really, REALLY weird issue that we're having with the application at my company. I'm going to try and describe this as best I can.
First, this is a legacy application with a Swing UI.
Second, the issue only occurs when it is compiled & run using Java 8. With Java 7 and below, this does not occur.
So, the issue: When a dialog is displayed (modal or non-modal, doesn't matter), the UI becomes unresponsive to mouse clicks. What's truly crazy, though, is the UI is NOT frozen. Hovering the mouse over something produces the hover highlight as normal. Keyboard commands are received perfectly. Mouse clicks, however, do not work.
This also only occurs on OSX. Windows and Linux don't have this problem. I'm running this on OSX El Capitan.
As far as code samples, it's affecting all dialogs across the application. JOptionPanes & JDialogs, doesn't seem to matter. Here's a simple JOptionPane declaration:
int n = JOptionPane.showOptionDialog(mcContext.getMapperView(), "xPath of dropping target can't be evaluated" +
"\nPlease, select xPath for dropped node",
"xPath calculation for dropped node",
JOptionPane.YES_NO_CANCEL_OPTION, JOptionPane.QUESTION_MESSAGE, null, options, options[0]);
This code IS being called on the EventThread, so I don't believe it's a threading issue.
I'm totally stumped as to the cause of this. So far we've ignored it by compiling and running it in Java 7, but at some point as versions progress we will need to deal with this issue more directly.
Anyone have any ideas?
Edit: Thanks for the SSCCE Idea. Now I'm more confused than ever. When I put together a quick frame/dialog demonstration, it worked perfectly. No issues. So I don't know what it is in the application that could be causing this. Any good places to start looking?
Edit 2: Wrapped one of the declarations in SwingUtilities.invokeLater, and it worked. Ok... now what could the culprit be? It's still got to be something that Java 8 is compiling different than Java 7.
Edit 3: More weird behavior. I moved my IDE into a separate "desktop" than the application it was running, and when the buggy dialog is displayed, i cant switch to that desktop. I can switch to any app on the current desktop, but not to another desktop.
Edit 4: The dialogs in question are being triggered by drag and drop actions. Not sure if that helps or not, but I do see that there is a thread in the background in the thread dump using the sun.lwawt.macosx.CDragSourceContextPeer class.
Alright, it took a while, but I think I found it. I found an OpenJDK post that seemed to very clearly describe this issue.
https://bugs.openjdk.java.net/browse/JDK-8139393
Somehow, Drag N Drop in Swing on OSX in java 8 isn't releasing its hold on the MouseEvent or Listener, so when a modal dialog is displayed the mouse isn't able to get new events through to it. Which is a crazy stupid bug, but it's there.
The solution was wrapping my code in SwingUtilities.invokeLater(...). By having the code that displays the dialogs executed asynchronously from the drag and drop code, the drag and drop operation is able to complete and release its hold on the mouse connectivity (for lack of a better description). And viola! Problem solved.
Thanks to everyone who tried to help. Hope this post helps out anyone else dealing with this issue.
In my tests chrome stucks after 30 or 40 minutes of work with error:
[710.758][SEVERE]: Unable to receive message from renderer
My current functionally is to take some txt data from web page and add it to inputs using executeScript. Can someone to help with this issue? Or just tell me correct way to resolve this problem
As far as I can remember, Chrome uses its own task manager... it can be opened by pressing shift+esc, assuming you don't have another program hooking that hotkey pair. Open the task manager and monitor the different tasks to see which one is bogging.
(couldn't leave a comment with low rep)
In my experience, this kind of error happens when you have something on the browser side which is preventing the part of Selenium that lives in the browser from doing its work. Whenever I've seen it, it was because some code went into an infinite loop. This would prevent the JavaScript engine from giving control to anything else and would prevent Selenium from being able to poll the renderer.
Besides the message Unable to receive message from renderer the other symptom would be a relatively high CPU usage from the test browser. Linux was pretty good about preventing the runaway browser from completely hosing my machine. I had to take a look specifically at the browser's processes to see the problem.
I develop RiboVision, http://apollo.chemistry.gatech.edu/RiboVision/
Some within the last few months, my site developed a problem on macs. I use the Jmol Java applet. It is not receiving mouse focus anymore, but only on Macs, and in all browsers, Safari, Chrome, and Firefox. It has to be related to some update Apple did to Java.
A really odd thing is that FirstGlance, does work on a Mac. It's basically the same Java Applet embedded in their page. http://bioinformatics.org/firstglance/fgij/fg.htm?mol=1d66&JAVA
I have no idea what I'm doing differently.
EDIT.
On a PC using Chrome, the applet works initially, but does not work after switching tabs. On a PC using firefox, it works correctly. On the mac, again, on all browsers, it doesn't work even the first time.
I don't know how to debug something so complex and elusive. No errors show in the console.
I solved this. Turns out, it was an issue with the z-index. I had the z-index of the Java applet set to -9000. This had no negative consequences before. I don't know when Apple changed something, but now it listens to the Z-index. I set the Z-index to something more appropriate and it's back to normal.
I am very new to Eclipse, java programming and well all "programming" in general and I have recently been learning how to use Eclipse. I've been using it for about a week now and it has been going decent so far. Apart from some errors,(mostly on my part) that has been fixable by restarting the program itself.
However when I started using it today I could no longer see the suggestions made from the Quick Fix command, for example if I type findVi and then press CTRL+1, it shows "No suggestions available" instead of "findViewById()" or something similar.
I know it's the correct binding, I even reset the keys to default to be sure. It still finds the ID if i type it manually but I would like to able to finish words faster that way.
If you guys got any suggestions that can help me out, please let me know.
Thanks.
- First of all if you are new with Java, and want to practice Java, you should NEVER USE ANY IDE, that way you learn the proper syntax, and it helps your error finding skills.
- But as you wrote "findViewById()" it seems that you are doing Android, Now this happens sometimes that Eclipse behaves weirdly with Android. Thats the reason when you make any changes into your Eclipse GUI while working with Android, its always better to see if those changes have taken effect.
- This problem usually goes off after closing and re-opening the Eclipse once or twice.
- Ok try this....
Type findVie then press Ctrl + Space-Bar See if the suggestion pops up...
You can access the Content Assist preferences from Window > Preferences > Java > Editor > Content Assist... perhaps something got messed up.
Problem:
Obscure error message http://img66.imageshack.us/img66/6746/confusedg.png
Conditions:
IE7, SP2, latest flash/java. Only reproducible on one machine.
Observations:
Smaller than a javascript alert box, and seems to be generated when a swf on my web page loads. The dialog is modal, however, like an alert box.
Issues:
I've tried matching the configuration of the machine in question, but a recreation of the machine does not get this error. I'm not ultra-familiar with flash/flex, so is there something that flex/flash could do which would cause this error dialog to appear.
How would one even go about debugging this? It's mostly not reproducible aside from a single machine, and the circumstances which cause the error are unknown. Thoughts?
Looks like a windows dialog to me. Neither Flash/Flex or Javascript. (though one could make either look like that if they tried).
The problem could be entirely machine dependent, it could be a virus, or it could be anti-virus or add blocker thinking the flash file is a threat. My automatic backup.recovery software sometimes pops alerts like that when it's in the middle of making a backup and I download something.
I'm meandering, my point is there are far more variables than just the browser and flash versions that could be coming in to play. I know that probably doesn't help much, but hopefully I've given you a few more ideas of what to check.
When you're setting up the "mirror" of your development machine, are you sure you're installing the version of Flash with Debugging enabled?
That might have something to do with it.
Have you tried using IE developer toolbar? http://www.microsoft.com/downloads/details.aspx?familyid=e59c3964-672d-4511-bb3e-2d5e1db91038&displaylang=en
Process Explorer would help debug this by displaying the call stacks of the IE7 process. You could then look at each call stack in order to find the one displaying the message box. This will show you exactly which modules are on the stack at the time the message box is displayed.