Could you please tell me why I have waiting mouse cursor in my gwt application as if page not fully loaded ? It doesn't happen on dev server. It only happens in production. Also it's happening in Chrome but doesn't in IE.
Link to my app is here.
Screenshot
I checked it again in Chrome, but for me no wait cursor is Displayed. But i think, your Google Chrome is trying to open the Google Translate Menu. For me it came quickly and the page loading stopped and the mouse was at normal position.
I prefer you try updating your chrome.
I have also checked the same in my co-workers Laptop and its working fine too.
If problem still persists, please use CCleaner Software and clear all Temporary files, Browser Cache, Recent files etc. Why because, GWT creates a lot of temporary files which may reduce your system performance. So after each cleaning, just restart the system also. I had few such resolutions recently.
I opened your link in Firefox and got the following error
ERROR: Possible problem with your *.gwt.xml module file. The compile
time user.agent value (safari) does not match the runtime user.agent
value (gecko1_8). Expect more errors
This is because, you have compiled your code for Webkit browsers only. If you have added a line as below in your gwt module xml file,
<define-property name="user.agent" values="ie6">
you may either remove it or you can add more browser support via this.
Related
When I use chrome to debug my angular project, I open files in the chrome sources by clicking Ctrl+P/O and entering part of the name. Problem is: when I reload, seems chrome keeps all the wrong files open... so if I debugged into another file (didn't close it! just lost focus) and then reload (like, after sources changed and compiled) chrome will close that file, and might even not remember it in the open recents dropdown... It's like someone sorted in reverse for some reason...
Is there a way to fix the wrong sorting order through settings or configuration somehow?
Am I the only one finding this not very smart/useful? Considering debugging in browser is a pain in the arse as it is, and unfortunately is the only/go-to option for debugging browser apps...
I'm using VSCode, Live Server plugin for HTML5 web development. When i make a change to my web page then save Live Server should refresh what i see within Firefox. It does refresh but it is always to the oldest cache of the web page when live server first started up. I must always tap CTRL-F5 to force a web page refresh within firefox. The moment i save again within VSCode, the browser display reverts right back to the oldest, first copy.
I've already tried enabling "Disable Cache" within the FF Dev Tools > Networking area. Didnt help. I've tried about.config | browser.cache.disk.enable set to false. Didnt help.
Just wondering if this is normal behavior or if the Live Server plugin (Ritwick Dey) for VSCode is broken.
At the present time
Ok it seemsthe problem was i was using a service worker (sw.js). The browser saw the file, autoloaded it and apparently took full control over caching in the browser -- basically, no matter what i did caching and refreshing was meaningless. I really need to understand this sw.js thing.
I am using Visual Studio 2019 v16.8.5 and have a single Blazor WASM PWA project in my solution that I recently upgraded to .NET5. In between I got it to run, but lately I cannot get to start it anymore.
The screen says Loading... and that's it.
The console output (Firefox) shows the following error: Microsoft.JSInterop.JSException: Could not find any element matching selector 'app'.
At some point this was running without this issue, but even reverting the solution to an earlier state does not bring any change and I still get a blank screen.
I found a github source saying "just remove builder.RootComponents.Add<App>("app"); from Program Main". If I do this, the error disappears and I just get a blank page saying Loading... with no errors in Console output.
Additional information: I now do a full cache cleanup (cookies and website files) after running the project in Visual Studio to prevent any caching issues.
What am I doing wrong that I can't see any of my pages?
Even after explicitely calling them like https://192.168.188.31:5555/login?
Depending on the template version used to create the initial app, a slightly different HTML is used inside the index.html.
Older version could look like
<app>Loading...</app>
while newer should like
<div id="app">Loading...</div>
In case, the first is still true, the corresponding declaration should be
builder.RootComponents.Add<App>("app");
For the second the line should be
builder.RootComponents.Add<App>("#app");
The second uses the id selector #.
Usually, the index.html is seen as a "static" file and is cached by the browser. So changes, you have done in that file are not reflected immediately. The easiest way to disable the cache is to open the developer tools, go to the Network tab and disable the cache.
why does this happen? I'm using eclipse neon.1 and tried changing the color of the font in the CSS3 code and it worked on both internal browser and IE9, but not on chrome. I restarted the server a lot of times and even rebooted the computer but it still won't be applied on Chrome....
Right click on the text and go to inspect element, see if it shows newly applied style in styles section in developer tools. If not you may need to clear cache using Ctrl+Shift+Delete and reload the app.
I need to inspect the website but my scripts are not listed.
I already tried to uninstalled chrome and resintalled it again.
If I pause javascript and trigger any javascript action it opens a VM-version of jquery but I need the real file, not the vm-loaded one.
Any idea?
A but or not?
Any workaround?
Following the discussion from the comments above, the issue was unrelated to the web app but the environment in which the Chrome instance was run in. It was likely a Chrome Extension or modified setting that caused this misbehaviour.
The resolution was to create a new Chrome Profile, since extensions and settings are not shared between profile instances. The next step may be to identify the particular extension or plugin at fault to avoid this happening again.