is it possible to reload the content of the viewport without reloading the whole inspector.
I would like to make some changes to a javascript file in the debugger then reload the page to see the temp changes I have made (on load), before I commit to the file and upload. Where I'm working at the moment there is caching I can't get round so I have to wait a minute or two to see what my changes do on load.
I have found the page I want to work with under source and can save changes, but really need to see some actions that are fired on the loading of the page.
Is this possible?
Thanks
you can't do that with chrome debugger tool. each JS resource will reload on page load so you will loose your change.
you can proxy tools like Fiddler which will allow you to load script from your local machine while loading a third party website. You can create a copy on your own machine and then use fiddler to intercept the call for that file and send your local copy instead
I'm looking to initiate a download in a webpage using either JavaScript or PHP. All of the examples I've seen use an iframe to load the source of the file. Unfortunately this method doesn't seem to work with all smartphone browsers, specifically my Samsung Galaxy S3. It seems to be a known issue with some of Android's stock browsers.
I cannot use a link because the download must happen auto-magically, and using document.ready or window.load to initiate a window.location call is not acceptable because even though the download initiates it stops all the JS functionality on the current page. I have some JavaScript that must run after the download has initiated.
Basically the flow is:
Show JavaScript progress bar to simulate download progress
Initiate download in background
Once progress bar finishes -> jquery.show new content on page (installation instructions)
Can't seem to find a cross-browser solution that will let me get through all 3 steps above.
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.
I'm building an Offline HTML5's App, which has several pages inside (10 to be more specific). When I need to change any of these pages, I simply change the manifest file to instruct the browser to update all files (As the HTML5 documentation recommends). But here is the problem that nobody talks about:
While the browser is downloading the files, my dear users rushes into the app and start using it, then they complain that the changes did not take place. After hours of testing, I realized that the browser is slower than my users. So here is my question:
How to detect when the last file of the manifest file is fully updated? or in other words, how to stop my user to stop using the app until the last file in the manifest is fully downloaded?
I don't find anything on the Web about this issue
Is there any Javascript?
Listen to the cached event in the application cache API.
How can I do this:
the page loads
javascript loads a remote PDF file into local memory
the user clicks a button/link
the system launches the PDF reader or starts a download dialog with the PDF file already in memory
In other words, it's a regular file download in the browser EXCEPT that the file has already been loading in the background in order to speed up its receipt when/if the user decides to download the file.
You would have to encode the file (perhaps via a servlet), then you could get it through an XHR, and write it into a data uri, which you could then attach to a button or link.
This technique would probably only work on small files and very recent browsers.
StackOverflow won't let me post an example link as a link, so to test the concept, you'll have to copy the following line into an html file and see if you can load the link:
pdf link
This worked perfectly in Chrome when I tested it just now, and worked partially in Firefox. It didn't work at all in my version of IE.
Another potential solution is to make absolutely sure that the pdf is being cached, and then try to load it in a hidden iframe. Whether this works or not will depend on how the user has their browser set up.
You should consider not doing it at all, given the difficulties.