I have a massive GWT project with using of spring framework. It's running on Jetty.
When I'm starting this web application - web browser goes to state 'Not Responding' for 10-15 second.
It's very odd, because I can't imagine reason why browser can hang.
Does any one know why such odd behaviour can occur ? Some calculations of javascript ?
It seems that projects starts in in GWT debug mode, and when it's starting GWT actually validates and prepares java code for debugging. In that time browser is in 'hanged up' state.
Related
I have an ASP.NET Core 3.1 Blazor Server-Side Application.
Recently a user has complained, that it does not work with the TOR Browser.
So I tried it out and had to find out, it works in only ~50% of all cases.
Every time I tried, I requested a new circuit for the request.
When it worked, everything was fine and even the speed was not that bad.
But if not, first, the tab is loading the source, showing the favicon and then nothing happens for a while.
Sometimes, if you are patient enough it looks like the first render happens, but the second and so on for all the async operations never happens.
Is there a difference between the TOR nodes, that prevents Blazor pages from working properly?
Tor by default blocks javascript, which blazor signalR is based on, so it can't effectively communicate with the server, disable noscript.
Also k
Load any xPage
Refresh db design
Reload the xPage by either F5 or Ctrl+F5.
then almost all functions stop working without any errors. E.g. nothing happen if you click buttons or menu items. After restarting web browser some functions come back but some still doesn't work. After cleaning browser's cache almost 90% UI start working but some still need to reload the page few times. Is there any xPage app properties or Domino properties to adjust to fix that problem and make xPage app work smooth even after design refresh
Design Refresh didn't reload custom Java classes when refreshing with 8.5.3 FP1. This was fixed, I believe, in FP2. But that doesn't sound like it's causing the problem here.
Design Refresh will not reload jar files. That requires issuing "restart task http" to the console. ("tell http restart" doesn't properly reload everything XPages needs.)
If your application is using a Single Copy XPage Design to hold its XPages design, that too will not update until you issue "restart task http" to the server. The design seems to be cached by the server for better performance, but refreshing the design of the SCXD database doesn't reload that design. It's unclear if that's your scenario here.
XPiNC may also not update immediately, but I've not tried that. The runtime there is basically in the Notes Client itself, so I could understand that it would not update.
Otherwise, I would echo Thomas's experience, I've not seen any other issues (and my applications heavily use Java). I haven't needed to clean the application following a design refresh. Existing browser sessions will have problems with partial refresh calls, I would expect that. But a refresh of the page make all functionality work.
There are two scenarios I would expect to have problems.
The first is if you are storing anything in sessionScope or applicationScope variables that are required by your application, but your code only loads those on a specific page. If you refresh the design, the scopes will get dumped and so not reloaded until you go to the specific page. Typically I put such initialisation code on my layout custom control, so a page reload will always initialise it if it's dumped by a design refresh.
The second is if another user accesses the application and has Build Automatically switched on, which could result in the application being rebuilt without you realising it. It doesn't sound like this is happening for you though.
I am facing issue (Error:500 Unexpected run time error ) in some cases when xpages based application is opened in Note 9.0.1 client. This issue is not reproduce because when you restart your client it automatically resolve the problem and its not come very often.
Initially we were using Server 8.5.3 but we have upgraded server to 9.0.1 FP4HF71. We have not observed this issue on 8.5.X clients.
Can anybody tell why this issue sometime occur on some machine and automatically issue is fixed when machine re-starts .
Anybody else facing same issue or not? Possible solution?
It works well other than xpages apps.
Thanks,
Qaiser
Is this while you're developing? If you make a change in Domino Designer and want to see the change in XPiNC, you need to close Notes and re-open. It's to do with how the applications are loaded and how the XPages runtime differs in XPiNC vs server. (My guess is that the XPiNC XPages runtime uses the .class files for the application loaded in memory, but building the application recreates those - it has to - so the files are no longer available for the XPiNC runtime.)
There's no way round it and my recommendation (and what I've used for XPiNC development on other projects) is develop and test in Firefox, then do a final review in XPiNC when complete. Troubleshooting in Firefox is significantly easier than XPiNC, even with Firebug Lite plugin, so it will be an easier development experience.
The biggest single different with XPiNC look and feel / processing is if #DbLookup and #DbColumn are coded with "" as the first parameter, which works on browser but is bad practice. Following best practice of using #DbName() as the first parameter will yield consistent results on XPiNC and browser.
It won't occur for non-XPages applications, because they are the only applications using the XPages runtime built into the Notes Client for XPiNC.
Try changing the port under Preferences -> Domino Designer -> Web Preview Port to 8080 or something along those lines. Maybe port 80 is already in use.
I am embedding an org.eclipse.swt.browser.Browser into a view in a modified eclipse (Indigo), for use as a preview pane of a form editor component. On a form model change or an element selection change the code renders the form via vaadin 6 and displays it in the browser component.
Now, this works like a charm in most cases. But for some highly complex forms the HTML+JS generated by vaadin generates a lot of stress on the browser, rendering it unresponsive for up to a few seconds. That in itself wouldn't be tragic (1), but as long as the SWT Browser component is busy rendering that stuff, the entire eclipse UI thread is blocked.
A simple way to reproduce this is to create an HTML page that blocks inside a javascript function (see https://gist.github.com/creinig/5150747 for an example) and display it in the SWT browser. As long as that JS function is running, the entire SWT application is not responding to anything.
The only info I've found on this problem are
one SO question (without resolution) and
one question on EclipseZone (unanswered).
Not that helpful :(
The API docs of the Browser component don't seem to offer any insight on whether its rendering is triggered periodically by the UI thread or if itself triggers something that blocks the UI.
Is there a way to decouple the Browser component's rendering from the SWT UI thread? Or anything else that could be done to protect the eclipse UI from hanging stuff in the browser?
(1): We need forms of this complexity level, we're already optimizing the rendering performance and a switch to vaadin7 will most likely also speed things up. But the problem will certainly persist, if only in reduced severity.
Not a real solution, but a workaround that Works For Me (TM):
As described here it is really easy to launch the system's default browser from SWT. So I'm going to add an option to the view containing the browser control that will "detach" the view by disabling the browser control and opening the system browser instead.
In case the linked page drops off the net, here's the gist:
org.eclipse.swt.program.Program.launch("http://my.funny.url/");
launches the application registered for HTTP URLs. In other words: the system default browser.
Happiness ensues :)
As part of a set of Coded UI tests, a menu is clicked. However, the menu (which uses Javascript) fails to load the menu options.
The menus work fine when I run the test manually. If I refresh the page while the tests are running (or re-launch the browser), the menu options then load.
But what is weirder is this only occurs on a remote test environment. When I run the tests locally on my own machine, the menus work even when the Coded UI tests are executing the tests.
It makes absolutely no sense to me why the menus would fail to load. Could the Coded UI tests be stopping the Javascript from executing (to load the menu options)? But why does it work when I refresh the page?
Comparing my own environment and the test environment - there are no differences that I can see. I'm testing against the exact same web application (the URL points to the same web server). It's the same version of Internet Explorer, and all the settings are the same, that I can see. Same operating system too (Windows 7).
Any ideas?
One thing to note is that the tests worked fine under IE7 document mode - although the Javascript behaviour could be different here perhaps. Currently, I have the tests running against the web application on IE9 document mode. Changing the document mode to Quirks mode also allowed the tests to work in some situations, but only for a few tests.
I've figured out the reason for this is that I have been recording tests in IE9 Compatibility Mode and under IE9 Document Mode. IE9 Document mode is not supported for action recordings with VS2010.
However, even if I switch the document mode to IE8 Document Mode during test playback on the remote environment, browser dialogs fail.
Therefore, there is no real solution to this problem.
Furthermore, I would thus contest Microsoft's claim that coded UI tests are compatible with IE9 (even with VS2010 SP1) for this reason.
So I'm left with no choice but to wait until VS2012 Coded UI test tools (which offer full support for IE9, supposedly) before I can test any web pages which have browser dialogs or JavaScript menus.
I ran into a similar problem - some of the advanced javascript on my page simply fails when a Coded UI test run by a test agent is attempting to manipulate it (VS2010, IE9 standard).
When switching to compatability mode (IE9 compat/IE7 doc mode) we had a different issue we just resolved - the innertext of the controls changed significantly, which was breaking our search/filter properties.
Updated those properties and the tests now work correctly in compatibility mode on the VM, or in IE9 standard on my machine.