Having run a Lighthouse report on my budding PWA, the report tells me that:
User will not be prompted to Install the Web App Failures:
Manifest start_url is not cached by a Service Worker.
But it is! I can SEE it in the cache in the "Application" tab on Chrome's F12 tools
I can confirm that the entry in the manifest.json is correct too as the "App Manifest" area in F12 tools shows this
I have tried changing it to work with just a basic HTML only page and get the same issue in the report. I have also tried changing the URL to just / but no change in the Lighthouse report.
What am I doing wrong?
This was due to a "buggy" Lighthouse. Its being constantly updated and improved and no longer reports my start_url as being problematic.
Another issue I came across that was driving me mental was Lighthouse reporting that the site was using HTTP/1.1 (with no compression) when various online resources were showing me it was using HTTP/2 (with compression) (IIS 10 automatically serves HTTP/2 if client supports it) It turns out that my antivirus was messing with HTTPS traffic - soon as I turned off HTTPS threat detection, Lighthouse was reporting HTTP/2 with compression.
Related
Anytime I have dev tools open on localhost my cookies are deleted and I am redirected to the login page on every page load which means I cannot use dev tools to debug or get insight into my site. I have localhost setup with a valid SSL cert (self-signed) and the site works normally until I open dev tools. How do I fix or disable this new "security" or setting in chrome?
After lots of issues and trying out many different things I came across this post/answer
When adding a Javascript library, Chrome complains about a missing source map, why?
Turns out that when I opened Dev Tools it would request a CSS map and the request was being sent to a different firewall causing my application to require me to re-authenticate every time this resource was requested. Turning off the CSS source map option fixed the issue
Open Chrome and navigate to google.com
In Fiddler use the "Any Process" button to select that Chrome tab
In Fiddler the "Any Process" button changes to something like "chrome: 11788"
In the Chrome tab search for something
I expect traffic to be captured by Fiddler but no sessions are displayed. If I use "Any Process", traffic is captured from all applications.
The "Use Filters" checkbox is unchecked in the Filters tab.
I uninstalled and reinstalled Fiddler.
I have the latest version installed.
What else could I do?
Modern versions of Google Chrome use separate process for making requests; so the process of the main window, detected by the 'Any Process' tool, is different.
The team is considering a fix, but it is currently not implemented, see "Target Any Process" feature no longer working with Chrome.
Possible workarounds meanwhile are:
Use other filtering functionality - e.g. capture a request from Chrome, and from the Sessions view choose right click -> Filter now -> Show only process=<process number>.
Filter everything else. In Fiddler, uncheck Tools -> Options -> Connections -> Act as system proxy on startup. Then Start Chrome with manually specified proxy settings, pointing to the port on which Fiddler is listening:
chrome --proxy-server=http://localhost:8888
This way the only captured traffic will be from this instance of Chrome.
Detailed version: Why Fiddler's Process Picker tool doesn't work with Chrome anymore
Brief version: For security and performance reasons Chrome now handles network requests through a separate network service. So when you are pointing the 'Any Process' tool of Fiddler on any Chrome window/tab, you are actually pointing to the UI (browser process) of Chrome browser.
There is one quick workaround for this:
Navigate to chrome://flags/#network-service-in-process in your Chrome browser. You would see Runs network service in-process and its value would be set to Default.
Change the value from Default to Enabled. By doing this you are telling Chrome to handle network requests from the browser process which also handles the UI.
Restart Chrome. You should now be able to capture network requests by pointing the Any Process tool on any Chrome tab.
Once you are done with your development activities do not forget to set the flag back to Default. This would give better performance.
NOTE: At the point of writing this, I am using Chrome 84.
what is deepMiner.min.js that suddenly shows up in web app? From chrome developer tools, it tried to load the file for 25 seconds, but failed.
https://jhondi33.duckdns.org:7777/deepMiner.min.js
The file is not explicitly included in web app.
For Microsoft Edge developer tools, it is always from cache even if cache is disabled.
UPDATE
If running the webapp from my local machine, the file did not show up in Chrome developer tools. Is this related to web hosting? But the web app is HTTPS secure.
The following is inserted into the web page that is dynamically generated (not static)
<script src="https://jhondi33.duckdns.org:7777/deepMiner.min.js"></script>
it appears to be a cryptocurrency miner that can be obfuscated as something innocuous. This has been done by hijacking the webpage with injected entries. See this similar issue in a Github issue. Update the host and DNS auth.
DeepMiner
After upgrading to Windows 10, I am receiving the ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY in Google Chrome (Firefox 39 just doesn't load the page) when I attempt to access my machine over HTTPS. I have a GoDaddy signed certificate for my computer.
I've attempted disabling most of my encryption ciphers per https://http2.github.io/http2-spec/#BadCipherSuites.
I've gone so far that I've disabled ciphers that are keeping me from RDPing to my desktop...and it still gives me an error!
Any guidance is appreciated.
Apparently you are not the only one having this issue: Disabling HTTP/2 / SPDY in HTTP.SYS and IIS in Windows 10
According to the error message this is a SPDY issue, so the certificate and the cipher suites are not the cause.
SPDY is a protocol allowing multiplexing HTTPS requests but it will be replaced by HTTP/2. As a temporary fix, you can apparently disable its support in you browser/registry/server.
I ran into this same issue after my win 10 dev machine got updated twice recently (the updates took around 35-40 minutes to deploy each time) and after this i was not able to run my Visual studio 2015 web applications over Https on Chrome but was able to run on IE
I tried out the registry method for disabling Http 2 as mentioned
here, but this did not worked for me
Then I came across the following solution: I downloaded IIS Crypto and
selected "Cipher Suites" option and clicked Best Practices button, and applied
it, My problem was gone and i can now run my web app over Https in Chrome just like before
Uncheck "Enable SSl" in your project properties under the Debug tab
I solved a similar problem by removing the parameter "Strict´Transport-Security" with value "max-age = 31536000; includeSubDomains; preload" from "HTTP Response Headers"
I've created a web app and placed it on our intranet web server. If an iPad loads the app while on the intranet network, the app works. If I turn on airplane mode, the app works in offline mode.
However, I believe (and I don't have a debugger to test), if the iPad then connects to the internet, the app tries to access the cache manifest as it sees it is connected to a network, but the manifest request returns a 404 as it isn't on the intranet. The appcache is then discarded and the application stops functioning.
If what I'm saying is correct, is there some way to mitigate the appcache from being discarded when the manifest returns a 404?
Thanks,
Chris
I am, fortunately, completely incorrect. You can indeed move from different network environments and the app will continue to function.
My issue was that my web framework will publish the minified version of some javascript files in Production mode, which I didn't include in my cache manifest.
What threw me is that Chrome would throw an error when it can't reach the manifest, which is apparently entirely expected in this case. Given that much of the material on the web points to the appcache being discarded if an error occurs during the cache loading process, I had thought this was what was happening. Forutnately, this particular error doesn't impact offline mode.