Recently, I encountered a very strange issue, this issue only happens in Windows XP SP3 and Vista. Here are my steps:
Create two new folders in desktop (assume folder names are A and B)
Copy Microsoft GraphEdit (graphedt.exe) application to A folder, then create a empty graphedt.exe.manifest file as well. Run graphedt.exe, you will see a error message, the graphedt.exe can’t run due to the wrong manifest.
Copy Microsoft GraphEdit (graphedt.exe) application to B folder, run graphedt.exe and close it, then create a empty graphedt.exe.manifest file, run graphedt.exe again, you will see the manifest file can’t apply to graphedt.exe. But if you change the last modified time of graphed.exe, the manifest will work again.
It seems Windows will remember the status the first time the EXE uses a manifest file, but also Windows will reset the old remembered status if you change the EXE size or last modified date.
[I'm the current SxS maintainer at Microsoft]
Good investigation Yigang. You're describing the behavior on Vista, not on XP SP3.
Probing for the existence of a manifest every time an app is run would be a performance issue, since usually apps either have a manifest or don't, and that state doesn't change much. For this reason, on Vista, the first time an application is run, we cache a bit describing "this application has an associated manifest" or "this application does not have a manifest". When you ran graphedt.exe the first time, Windows cached the absence of a manifest, and will subsequently not look for one. To reset the cache, update the last modified time on the executable.
Related
I have a progressive web app and I wish to make changes to its manifest file like a change to its start_url, scope, icon, name and short_name. I wish to know, when is it that the updates to the progressive web app take place after making a change to its manifest? I tried the following to force update the web app on Chrome browser:
Launch WebAPK
Close the WebAPK
Modify the Web Manifest
Advance Android's system time by 3 days.
On my device: Settings>System>Date & Time>Set date
Launch WebAPK, wait a few seconds
Run adb shell dumpsys jobscheduler | JOB.*91.*org.chromium.components.background_task_scheduler.BackgroundTaskJobService
Check that the output is not empty
Close the WebAPK
Run adb shell cmd jobscheduler run -f com.android.chrome 91
to force an update
However, I wish to know what is the real criteria for update to the web app after a change to the manifest file is done? Please can someone attach a code snippet supporting the same, which may be specific to how Chrome implements it?
I did a deep dive, to know what exactly is the criteria for update of web app on changes to manifest file and I was able to find the relevant source code in the chromium code base which had the update logic. According to the latest chromium source code changes https://chromium-review.googlesource.com/c/chromium/src/+/1635860 , the update interval is set to 1 day (99% cases, where the apps may update more frequently) and 30 days (1% cases where the apps may update less frequently). Previously, it was set to 3 days ( 99% cases) and 30 days ( 1% cases). Also, there is an official documentation by Google https://developers.google.com/web/fundamentals/integration/webapks#update-webapk which says :
Chrome will periodically compare the locally installed manifest against a copy of the manifest fetched from the network. If any of the properties in the manifest required to add the PWA to the home screen have changed in the network copy, Chrome will request an updated WebAPK, reflecting those new values.
There are a number of rules that govern how these update checks are triggered:
Update checks only happen when a WebAPK is launched. Launching Chrome directly will not a trigger an update check for a given WebAPK.
Chrome checks for updates either every 1 day or every 30 days. Checking for updates every day happens the large majority of the time. It switches to the 30 day interval in unlikely cases where the update server cannot provide an update.
Clearing Chrome's data (via "CLEAR ALL DATA" in Android settings) resets the update timer.
Chrome will only update a WebAPK if the Web Manifest URL does not change. If you change the web page from referencing /manifest.json to reference /manifest2.json, the WebAPK will no longer update. (Don't do this!)
Chrome will only update a WebAPK if the WebAPK is not running. Moving the WebAPK to the background is not sufficient if it keeps running.
Only WebAPKs created by an official version of Chrome (Stable/Beta/Dev/Canary) will be updated. It does not work with Chromium (org.chromium.chrome).
The update check may be delayed until the device is plugged in and has a WiFi connection.
Validated the same already.
The code flow responsible for this update is given by follows :
Whenever, there is an update to the manifest file at the same origin, an update task is scheduled in the background service by the WebApkUpdateTask the link of which is given as follows : https://cs.chromium.org/chromium/src/chrome/android/java/src/org/chromium/chrome/browser/webapps/WebApkUpdateTask.java .
This update task is managed by the WebApkUpdateManager , the link of which is as follows : https://cs.chromium.org/chromium/src/chrome/android/java/src/org/chromium/chrome/browser/webapps/WebApkUpdateManager.java?sq=package:chromium&dr=CSs&g=0
The check for updates interval is done by the WebappDataStorage , the link of which is as follows : https://chromium.googlesource.com/chromium/src/+/652f0ba0d8d29ba7508654bf20172d3c83a784fb/chrome/ android/java/src/org/chromium/chrome/browser/webapps/WebappDataStorage.java (https://chromium.googlesource.com/chromium/src/+/652f0ba0d8d29ba7508654bf20172d3c83a784fb/chrome/android/java/src/org/chromium/chrome/browser/webapps/WebappDataStorage.java)
I can add a folder to the workspace (which doesn't seem to do anything, as far as I can tell), but the "map to file system resource" option seems to have been removed, and I can no longer live-edit css files.
Is this a bug, or has the process for mapping css files been changed?
This talk (https://developers.google.com/web/updates/2017/10/devtools-release-notes) says that the new version uses "magic" to map remote files to local ones, but I can't seem to get it to work at all.
For reference, I'm trying to map a reddit css file to one on my own computer. It worked fine on a previous version of Chrome (basically I add the folder, and map the css file inside it, which has been renamed to have the same name as the remote one) but not on the new one (Chrome 63)
I've just fiddled around with a problem, where only some files got mapped to my local workspace.
Turned out that Google Chrome also checks and compares the last modified date of your files.
If the file on the server has a more recent date than your local copy, this file won't be mapped.
I deleted the Bootstrap file on the server side and uploaded my local copy, which has an older last modified date. Google Chrome instantly mapped the file to my local workspace.
Out of curiosity I ran touch bootstrap.min.js on my server to set the last modified date to today. This broke my file mapping again.
Chrome removed manually mapping to filesystem resources because of the new Workspaces 2.0 (See: https://developers.google.com/web/updates/2017/10/devtools-release-notes).
You should be able to drag and drop your folder into the sources tab and it'll link the files automagically.
However automatic mapping doesn't work in many situations and there is a Chrome bug to re-add manual mapping
I had the same problem so I downgraded to Chrome 62 (preferences, history, extensions and so on are preserved).
Download Chrome 62 from
https://www.slimjet.com/chrome/google-chrome-old-version.php .
On OS X trash /Applications/Google Chrome.
Switch off auto-update by setting "defaults write com.google.Keystone.Agent alwaysPromptForUpdates 1". Default is 0.
May be you have to set "defaults write com.google.Keystone.Agent checkInterval 0" too. Default is 18000.
Install Chrome 62 as usual.
After starting Chrome 62 open "About Google Chrome". Chrome is checking for updates, but will prompt you to confirm.
The "Map to File System Resource..." menu item is missing. There appears to be no way to map files. It is completely broken as far as I can tell.
For me, the problem turned out to be the presence of the copyright symbol © in the file headers (which affected just about every file). With this character in the files, devtool refused to map the files but with it removed, the files map fine.
I'm also using Chrome 63.0.3239.132 (Official Build) (64-bit) and as I wanted to use the DevTools Live-edit to edit some js files I saw that the option "Map to file system resource" is missing.
After some research I have found out that the Live-edit is perfectly working in Version 63, you just have to:
go to Sources and then FileSystem
add the folder with your code to the workspace
After that, a small little green point will be displayed near your files (it means the synchronization is ready) and the changes via DevTools can be persisted locally:
Thanks to others in this thread saying chrome is checking the modified date.
Adding this to .htaccess solved it for me
IndexOptions SuppressLastModified
Of course you would not want this to get into your production code as it could stop browser caching working.
I cleared the cache and it works now.
Previously, I opened my CSS file from my FTP client, then I dragged the containing folder into the Sources tab > Filesystem tab (without caring about any folder names nor structure, I just dragged the FTP clients containing folder into it).
The persistent mapping worked straight away, edits from the Chrome Dev Tools were saving on the server. After 30 minutes of fiddling and playing around, it just stopped working and the CSS resource got greyed out. The file icon with the green dot was not appearing anymore.
It didn't matter what I'd do, it would not work, but when I cleared my cache, it started to work again.
File mapping started working reliably for me once I turned on a devtools setting -- click the upper-right gear icon and check Preferences > Network > "Disable cache (while DevTools is open)"
As of today, with Chrome Version 63.0.3239.108 (Official Build) (64-bit):
The feature appears to be still broken, not working 'automagically' nor consistently with the previous behavior.
However, adding a folder that reflects the resource's URL as seen in the Network tab, make it work again. So if for instance, in the Network Navigator tab you have:
http://mylocal.site/wp-content/themes/mytheme/assets/sass/partials/_header.scss
You will just need to add the whole wp-content/ folder to the Filesystem tab to get the feature work again as expected.
Had the same problem, but when my source maps included sourcesContent, the file mappings were automatically made and I could live edit my scss. Apparently chrome uses the content to find the right file.
node-sass --source-map-contents
I found the following issue here in stackoverflow however cannot comment as yet. I have a similar issue and wonder if there is anyone out there that has solved it.
https://stackoverflow.com/questions/40917501/tfs-2015-web-portal-code-viewer-not-working#
I am encountering similar here. In house TFS 2015, can't view code in the web portal using Google Chrome however IE is fine. I, however, am not using HTTPS so may be experiencing something slightly different.
When I do try to view a file in Chrome, the window where the code listing should be is simply blank. I did note too that the button for creating a new build definition appears to be indicating a broken image link.
This has not always been an issue. Around 4 months ago I could get the code view fine in Chrome and, to my knowledge as I have no access to the servers, nothing has changed apart from Chrome updates.
I've tried getting to previous versions of Chrome to no avail, though I wouldn't know which version I was on when this did work.
Interestingly, I have one or two .MD files around and these display perfectly well. They are simple text files. However when saved with .TXT extension (or anything else I've tried), they do not show. Curious.
Update
As you will see from the screenshot below, when selection on a file has been made, in this case a .SQL file, where I would expect the view to populate nothing at all appears.
As for the F12, I do get 5 of these:
Failed to load resource: net::ERR_CONNECTION_REFUSED
plus associated paths of course. We use Webroot internally here which has recently dropped in a Chrome extension however even when Webroot is disabled in its entirety (including removal of extension) I get the same behaviour.
All other Chrome extensions have been removed too at varying times to try to give a clean browser.
I have no other pop up blockers, ad blockers, etc installed on the workstation.
Problem solved thanks to the F12 key suggestion.
After some grovelling I was granted domain admin privs to have a dig around everything. It turns out that TFS was installed on ServerA with a URL port of 8080, this I knew from the original install and obviously the path I follow to get to my TFS web interface. What had also been done subsequently, with no consultation of the Dev user group, was that a second TFS application tier had been installed on ServerB, the port here was 8088.
I had not noticed the difference in path initially, assuming it was Chrome or workstation related. Anyway, I altered the port on ServerB to 8080 and everything jumped into life. I should not have made assumptions and should have paid more attention to the path in the error!
It seems the second application tier was set up on a non-production environment to allow senior Dev users access to the TFS Management Console rather than allowing them access to the original app tier which was on a production box. Our IT Operations just forgot to tell anyone.
Try to update your chrome to latest version of (55.0.2883.87 m (64-bit)).
Also clear the cache of chrome. I have also encountered similar issues. The solution is clear cache and connect to the web portal use another ID, then connect back use the original ID. I have no idea which one solved the problem. You could try both.
This problem should only be an individual phenomenon, since TFS2015 has been released for a long time.
I have a 3rd party executable which I am trying to include in an InstallShield MSI package and I want it to have permissions set in all flavors of Windows, particularly 7 & Vista to be run as Administrator.
I'm not that clued up on the creation or the proper configuration syntax of Manifest files, but I have tried to make one manually as [appname].exe.manifest, and tried the <requestedExecutionLevel level=”asInvoker” uiAccess=”false” /> in the XML, and it didn't run as Administrator, and I want to confirm that is that because the program had not been compiled that way to see that the manifest file was in the same directory, or is it just going to be a case that the manifest file has not got the right syntax.
If there is any other simple ideas, I would love to hear it!
Cheers.
Manifests can either be embedded into an executable (this is preferred) or external, placed next to the file named as you describe. If there is an embedded manifest, an external one is ignored. For launching EXEs, this is all performed by Windows, and is not affected by code in the exe file. For loading DLLs, while this can be somewhat influenced by code you write, it does not change UAC behavior as it is not a process boundary.
As for whether a program not launching as administrator when you place a manifest requesting asInvoker next to it means you created a valid manifest, that depends on what happens when the manifest is not there. Since you mention InstallShield, you can copy a template manifest file such as its <InstallShield>\Support\setupexe.invoker.manifest to ensure your syntax is correct.
Upon re-reading your question, I realize you wanted it to launch as administrator. For that you need to request administrative rights, so you should have requireAdministrator instead of asInvoker, or base it off setupexe.admin.manifest instead.
I'm using HTML5 appcache and mostly it's working well. However, sometimes, users' browsers (Chrome or Safari) will hold onto the cached manifest file even though I'm positive that the server has a brand new manifest file with a unique version number inside of a comment (like with "# app version 1.0.0.8" or whatever).
In IIS (version 6), the content expiration was set to 1 day, so could that be the problem? I can't seem to reproduce this issue which makes debugging difficult. As a precaution, in IIS I've changed the content expiration to "expire immediately" for the directory that stores the manifest file. Could that explain why some browsers were hanging onto manifest files even when a new version was available?
I also noticed that when a browser was behaving this way, even if I deleted the manifest file on the server, the user's browser would use its own cached copy of the manifest file which isn't supposed to happen if the file is no longer available in my understanding.
Thanks,
Andy
Taken from my answer here : https://stackoverflow.com/a/13282735/727575
Yes, this is the current "correct" behaviour. It has nothing to do with IIS content expiration. This is what happens:
When you just made changes to the manifest file, and you refresh the browser, this is what happens (assuming you're online)
the browser first loads back all the files in the cache
then the browser check online for your manifest file
it detects that the manifest file has changed, it will then proceed to download the new files
however, keep in mind, at this time, you will still be looking at your 'old files' because the browser has loaded the old files before going online to download the 'new files'
if at this point, if you hit refresh again (2nd time), you should get the 'new files'
This is currently the standard behaviour. Some people put some event handlers to prompt the user to do another refresh (after the 1st refresh)
So basically, you need to refresh twice or throw one of the event from 'window.applicationCache' to handle it
To look at an example of using window.applicationCache, go here : http://www.html5rocks.com/en/tutorials/appcache/beginner/
it's under the "Updating the Cache" section.