On this page in Opera on Windows, pressing the refresh button or F5 doesn't refresh the frame with the game in. Does anyone know why?
It's a bug. When a request for the main FRAMESET file gets a 304 Not Modified response, Opera will not re-load the frames inside. Try right-click, "Frame > Reload" instead.
I thought so. I filed a bug report for it (DSK-320851). Would be great if it was picked up.
As it stands I rewrote the entire site to use static html, with the frames even inlined. So that effectively means Opera can't refresh any of the demo's. Kind of sucks... I was afraid it was an edge case (side effect for inlining the frames), but I guess it's not.
The alternative is to press enter in the address bar btw. That does properly refresh the frames.
Related
Attachment
I'm currently working on a website.
Attached is the part of the website that I can watch on my computer monitor.
Changed Display below is the what I want.
However, if I keep hitting 'ctrl+f5', the screen shows me either unchanged display or changed display.
I have no idea why it shows me two different types of screen.
As far as I know, 'ctrl+f5' deletes the cache and updates data but it is not for me.
Ridiculously, If I keep hitting 'f5', I can only have the changed display as I want.
I guess I have a problem on css because I get an error message: DevTools failed to load SourceMap: Could not load content for http://localhost:8090/asset/css/sub.css.map: HTTP error: status code 404, net::ERR_HTTP_RESPONSE_CODE_FAILURE.
Does anyone know the keys on this problem?
There's not enough info here for anyone to tell you how to fix your problem with any amount of certainty.
What do you mean by changed display? Just the website looking different? Or a different debug preview (like scaling your website down to a phone's screen size)?
If it looks different, that might just have to do with caching.
The difference between CTRL + F5 and just F5 is that CTRL + F5 doesn't use your browser's cache, instead fetching everything fresh from the server, whereas just F5 uses your browser's cache. Your browser generally keeps track of when it cached things and will automatically fetch data anew if the time of caching was too long ago.
The former generally takes longer to load, naturally, which might be why the website looks different, at least until everything has been loaded.
Other than that, CSS gets a little weird sometimes, applying styles in a weird order. This generally has to do with the order in which, and where in your HTML document you actually load your stylesheets. Generally, loading all of them in the head of the document is a good idea. Complete redefinitions of styles in separate stylesheets can get very weird, even if it should follow normal precedence (Thread on CSS precedence)
Though, again, you'll have to elaborate on your problem further, maybe provide some screenshots, for anyone to be able to definitively help you.
I'm trying to write a test for a simple API, which always fails because of a strange browser behaviour.
The response coming from the API is just some plain text:
foo-bar-123
I can see exactly that in the browser window and also as response in the network tab.
Okay so far, but when I look at the Inspector, I see something like that:
<html><head></head><body>foo-bar-123</body></html>
If I control the browser with selenium, the result of webdriver.page_source is the same.
For reasons I don't understand, the browser adds some HTML tags to the content.
Is this some strange kind of "feature"? Can this be switched off?
I don't think it's a bug because both Firefox and Chrome are showing this behaviour.
I just want to get the real content without any fancy stuff the browser thinks I need.
We have an API which randomly takes high content download time in chrome, It works fine always in firefox and takes an only few ms. The response size is 20kb uncompressed and 4kb compressed. The same request also works fine using curl.
Things that we have tried:
Disabling If-None-Match header to disable cache response from the browser.
Trying various compressions (gzip, deflate, br).
Disabling compression.
Disabling all chrome extensions.
The same request works fine sometimes on chrome but randomly returns very high content download time.
We are unable to understand the root cause of this issue. What are the other things we can try to minimize this time?
I made three requests here and the 3rd one took the most time (before the last spike). CPU does not seem to be maxing out for a longer period of time. Most of the time is idle time.
Also, When replaying the call using Replay XHR menu, the Content download period drops from 2s to 200 ms.
Are you by chance trying to implement infinite scrolling? If you are, try dragging the scroll bar instead of using the mouse wheel. For some reason, Chrome seems to struggle with mouse scroll events. If the scroll bar worked just fine, keep reading.
This post provides a detailed walkthrough of someone experiencing something similar - https://github.com/TryGhost/Ghost/issues/7934
I had attached a watcher on the scroll event which would trigger an AJAX request. I had throttled the request and could see that only 1 was being sent. I watched my dev server return the response within a few ms but there would be a 2 second delay in chrome. No render, no api calls, no and scripts executing. But the "Content Download" would take 3 seconds for 14kb. No other browser had this issue.
I stumbled upon suggestions that using requestAnimationFrame instead of setTimeout would solve the problem. That approach seems that approach works when the "Waiting" or green is significant, not so much for the "Content Download" or blue.
After hours of digging, I tried conditionally calling e.preventDefault() on the mousewheel event and to my amazement, it worked.
A few things to note:
1) I did not use the mousewheel event to make the api call. I used the scroll event along with throttling.
2) The mousewheel event is non-standard and should not be used. See https://developer.mozilla.org/en-US/docs/Web/Events/mousewheel
3) BUT in this case, you have to watch and handle the mousewheel event because of chrome. Other browsers ignore the event if they don't support it and I have yet to see it cause an issue in another browser.
4) You don't want to call preventDefault() every time because that disables scrolling with a mouse :) You only want to call it when deltaY is 1 if you are using vertical scroll. You can see from the attached image that deltaY is 1 when you basically can't scroll anymore. the mousewheel event is fired even though the page cannot scroll. As a side note, deltaX is -0 when you are scrolling vertically and deltaY is -0 when scrolling horizontally.
My solution:
window.addEventListener("mousewheel", (e) => {
if (e.deltaY === 1) {
e.preventDefault();
}
})
That has been the only solution that I've seen work and I haven't seen it mentioned or discussed elsewhere. I hope that helps.
console log of mousewheel event
I think you may be doing it wrong.™
Fundamentally, if this really only happens with Chrome, then perhaps the client-side code is to blame, of which you don't reveal any details.
Otherwise, you are trying to debug what you present as a backend condition (based on the choice on the nginx tag) with front-end tools:
Have you tried using tcpdump(8) to troubleshoot the issue? What packets gets exchanged and at what times?
Have you tried logging the times of the request being received and processed by nginx? E.g., $request_time?
Where is the server located? Perhaps you're experiencing packet loss, which may require timeouts and retransmission of some TCP packets, which invariably will introduce a random delay?
Finally, the last possibility is that the field doesn't mean what you think it does -- it sounds like it may take a hit from CPU load, as this is the result of the XMLHTTPRequest (XHR) processing -- perhaps you run some advertising with user tracking that randomly consumes a significant amount of CPU, slowing down your metrics?
Safari recently went to version 6 (Lion/Mtn Lion) and they've changed over from the standard webkit dev tools to one that's much more XCode looking, my problem other than the OCD of not liking things change is that in the resource tab (or anywhere you can track down the DataService.aspx/AJAX calls) I can no longer see the form data that I am passing.
Can anyone point me to where I can find that data so I don't have to console out my params when I'm testing new data service/backend calls?
I've logged a bug with Apple, they've marked it as a duplicate so hopefully they've received enough requests to fix this, until then I'm continuing to use chrome as the webkit developer is the same as safari's old version.
You can find this info in Instrument tab (stop-watch icon). In the left sidebar thers Timelines row, click the grey circle (record button) on the right. Then click to Network Requests where you see all reqs, and you have to click small icon on the right oc request to display response headers and all form data are available in right panel. Panel can be hidden same as left one (in case you dnt see it).
Unfortunately there are no query pamaters listed, according to this disscussion. I belive its a bug in safari
Edit 15.May 2013: This bug was fixed in Safari 6.0.3.
As far as I can tell, there's no way to show the request parameters.
This goes even further. I can't see the JSON response data either (no clickable arrows to show the containing Javascript objects within the JSON, just pure text)
I think we have to switch to Firefox /w Firebug or regular Webkit in order to get XHR monitoring...
Guys if you want to see post data in safari 6 which is not possible right now, install the firebug lite extension and there you go you have the post data.
I used it and it works great with safari 6
Actually the request headers, response headers and query parameters are in the details sidebar on the right when using the resources view or if you click to see the content of a request in the Timelines/Network Requests view. Took me a few minutes to find that too.
If you need to see what the device is actually sending and your server is on a Windows Machine I use http://www.Wireshark.org and check on the server side of things. No interpretation by any WebKit stuff and very valuable (such as issue with iOS and the 'Blob' data). Similar network snooping should exist on Mac as well.
I have a UIWebview. Let's say I open google in that view and then I press the back button and come back to Webview page again. Is it possible to see google (already opened) instead of loading that page again?
Yes indeed, it is called caching. It basically saves the page in memory so that it can be called later without loading. The only major problem is that if your "cache" (save) a page, if the page is updated on the internet it will not be updated in your app until the page is refreshed and loaded.
There is a lot of information on caching for iOS, just search on the Internet. A helpful link I found is this Stackoverflow question which shows you how to cache content.