I am working on HTML/CSS/JavaScript from within emacs. My workflow is currently
Make a change -> Alt-Tab to browser -> F5 (refresh) -> Alt Tab to emacs
Do any extensions exist that would auto-refresh the browser on a change? Or, possibly a better idea, when I hit a key combination from within emacs?
I've tried impatient-mode and it worked nicely for what I needed. It also can be extended to do things like, for example, display the contents of a buffer you are editing in an iframe alongside other buffers etc.
Option 1, refresh the browser on interval:
With the addition of a single meta tag into your html document, you can instruct the browser to automatically refresh at a designated interval number of seconds:
<meta http-equiv="refresh" content="3" />
Option 2, firefox plugin to refresh on document change:
A Firefox Add-on, called XRefresh, will monitor your project folder, and, every time it detects a change to the source files, it’ll reload Firefox.
Option 3, refresh the page from Emacs, vim or shell script:
There is a firefox plugin called IMACROS that let you define a script that will remote control firefox from a file on disk. You can create a remote control script, and then program Emacs, vim or shell script to tell firefox to run the remote control script when you are ready, thus refreshing the page. You would need to create a keyboard hook to kickoff the script on save.
I use Yeoman, which help you scaffold web apps, which uses Grunt and the command
$grunt server
It is a simple setup that enables "livereload". I then set up my localhost or rather IP:9000 which enables live reload of any device in my local network upon file save of all watched files (scss, js, coffee, html) etc. So you can see the site change upon save not only on your desktop, but your tablet, mobile devices, cross browser, smart tv etc..
It also runs compass, unit tests, uglifies & concatenates, does the dishes, walks the dog you name it. Then "$ grunt build" creates complete distributions to deploy.
It's worth a look, it's a bit of a setup, I had a few hurdles, but it's amazing what you get back.
Related
I have a UWP (JavaScript PWA template / VS 2017) that is meant for testing and development of a hosted application. There is not much fancy about it besides letting a developer or tester choose which application build it should navigate to. However, one thing annoys me and I cannot seem to fix it. In a previous incarnation of this UWP, anytime I opened it on Windows 10 and navigated to an app build, it would show a back button at the top that I could use to go back to the index.html for the UWP.
I have scoured the old code to see if I was missing something. I was thinking perhaps I had left out some code to enable the back button and handle when it is clicked. Something that might have looked like this:
// This is javaScript
const navigationManager = window.Windows.UI.Core.SystemNavigationManager.getForCurrentView();
navigationManager.appViewBackButtonVisibility = window.Windows.UI.Core.AppViewBackButtonVisibility.visible;
navigationManager.addEventListener("backrequested", window.history.back, false);
However, there was no such code in the old version. I also checked the code for the hosted app and I didn't find anything like it either. Regardless, whenever I open the old solution for this UWP, I get a back button with all the expected functionality but without any code to handle it.
Is there some kind of declaration in the app manifest or .jsproj maybe? Something that tells the application at build time that we want a back button that works "out of the box"?
UPDATE
I recreated the UWP with a fresh template and did some tests on it. The template automatically sets the start page to https://example.com and on this site there is a link for https://www.iana.org, so I whitelisted that domain in the content URIs. Navigating to the link there works. I get a back button.
Next, I replaced the template code with my own code, pointed it to index.html as the start page, and set up the content URIs. When I try to navigate to anything, I do not get a back button. Even if I go to https://www.iana.org, I do not see a back button.
Last, I replaced the start page with https://example.com. When I click the link on that page for https://www.iana.org, I get a back button.
I also removed all JavaScript utilizing WinRT in order to check if something there might be messing with it, but it had no effect.
Additional Info
After having a look at the old version, a major difference I see is that the index.html for the app was actually hosted and in my version it is part of the app. Per recent comments on this question, it seems that the back button functionality only works for hosted content?
For security reasons, the PWA project requires the project to run in the https environment, or it can be run in localhost when debugging locally.
The PWA project in UWP is to package the existing PWA program. This requires that the PWA project is already in the https or localhost environment. You can view some requirements of the PWA project here
Thanks.
I am trying to edit a JS file in chrome dev tools and half the time it works but the other half of the time the server JS file is cached and it used that, despite my changes.
I am trying to test a production feature only so I need to test it this way -- is there a way to ensure I can edit the chrome JS files so that it reflects each time in browser when testing?
Chrome has a feature called Local Overrides, which is basically this. It allows you to use a file location from your computer to load the webpage assets from, which you can modify, and the modifications will persist. Once you turn off the feature, it will revert to what is being served from the pages host (or cache), but you can re-enable and continue on.
As a word of note, this is only available (as far as I know) in Chrome V65+
Chrome 65 Release Video
We are currently using Webpack with the HtmlWebpackPlugin to generate our javascript builds for our webpage.
new HtmlPlugin({
template: 'www/index-template.html', //source path - relative to project root
filename: 'index.html', //output path - relative to outpath above
hash: true,
cache: true //only emit new bundle if changed
}),
This causes a hash to be added to the query string of the bundled javascript file.
<script type="text/javascript" src="/build/vendor.min.js?4aacccd01b71c61e598c"></script><script type="text/javascript" src="/build/client.min.js?4aacccd01b71c61e598c"></script>
When using any standard desktop or mobile browser, new builds are cache busted properly and the new version of the site is loaded without any effort from the user. However, we also have a chrome web app implementation where we call:
chrome.exe --app=http://localhost:65000 --disable-extensions
In this application, for some reason the hash on the end of the javascript build doesn't bust the cache. We have to manually right click somewhere on the page, then click reload (or press F5). For some reason the cache isn't busted in the web application.
I was thinking that possibly it is caching the index.html file maybe? That may cause the app to never receive the updated hash on the build. I'm not sure how to solve that issue though if that is the case.
I have also noticed that if our localhost server is down, the page still loads as if the server were running. This indicates to me some kind of offline cache. I checked the manifest.json parameters and can't find anything to force a reload.
I have also tried these chrome command line switches which did not help either: --disk-cache-size=0, --aggressive-cache-discard, --disable-offline-auto-reload.
Another caveat is that we need to retain the localStorage data and their cookies. In a standard browser window, or any browser for that matter it works just fine, but not when it is inside a Chrome web app.
Are you talking "Progressive Web App" with service workers? If so then the html file can (and should) be cached on first download. You need to have some sort of aggressive update process on the client to ensure new files are loaded properly.
Perhaps having an api call that checks some sort of dirty flag on the server could work, and if it comes back true, it should reload the template files. Or something more complex where it gets an array of dirty files from the server so it knows which ones to reload instead of loading everything. Just some ideas.
As your page works without the server running at localhost, I suspect that your app is offline first. This is done exactly through service workers(as pointed out by #Chad H) which are officially supported by Chrome and are experimental in other browsers. So, expect different behavior in other browsers. To bust the cache,
In Production
For a permanent solution, you to find and modify the service worker (SW) code. Deletion of old caches happens only in activate event of SW.
You can also read more about Service worker and ask a question with the updated SW code. Also, check out this resolved issue that faced a problem similar to yours.
For dev setup
You can use the Disable Cache option under Network tab in Chrome DevTools (works only when DevTools is open) or use a more robust chrome extension called Cache Killer.
I'm pretty new in VS Code, and I'm looking for an automated solution to debug Haxe JavaScript project.
A way to open or live-reload browser after compilation, like in FlashDevelop, Intelij.
Now, I use an external localhost server (MAMP), and after each build I reload the browser manually. It works, but is not very efficient.
Lets me know how you do that. ;)
For info, I'm on mac
Check out the MIX Live Server extension. You can give it a path to your index.html, for instance if it's build/index.html:
{
"mix.rootPath": "build"
}
and then it will detect file changes and reload the page automatically. Note that this does not open the page in a browser, but a separate VSCode tab.
I have a simple <input type="file"> in a web form (to be viewed in a browser) and I need it to work on Android (besides other mobile devices and desktop).
Due to a well known but still unfixed bug in Android (https://code.google.com/p/android/issues/detail?id=53088), any such input field may miserably fail to work, because while you are choosing for the file to upload (with whatever application, e.g. the Gallery or a third party file browser), the browser activity is in the background and the system may kill it at any time (no matter how huge your RAM is), and hence the page may reload when the browser activity is restored, and the file you've selected will be forgotten.
This still happens in Chrome on Android 4.4.4.
Of course it does work at times, but not always, and it's unpredictable.
I can think of (painful to implement) workarounds for a webview within a native app, but I can't think of any workaround in pure html+javascript for a web page to be visited by a browser.
The thing is, some workaround must exist, because there are web pages out there with file uploads that never occur into this issue, such as m.facebook.com to name only one. EDIT: forget this paragraph, facebook and twitter are affected as much as every other web page with uploads (and btw, Instagram's mobile web page does not allow upload at all, funny huh?)
Does anyone know what the working workaround is? Or if any exists at all?
Just to be clear, I need a workaround that can be applied by just adjusting the html and/or adding no-matter-how-much javascript code, but without forcing the user to install any specific extra app.
"interesting" problem...
It is not a ready-to-use solution, but you could save the state of the page before requesting a file:
http://www.html5rocks.com/en/features/storage