Develop Reference

Drag a file out of the browser

Most tutorials on javascript drag and drop explain how to handle file drops into the browser and how to drag data out of the browser. But I have seen almost nothing about draging a file out of the browser.
For example, you start a drag on a div element, drop it on the desktop and a file appears there.
What I have found is this: (from this example)
e.dataTransfer.setData('DownloadURL', `image/png:Luigi.png:${e.target.href}`);
However, as far as I can see, setting using DownloadURL this causes errors in chrome, a crash report in edge and doesn't do anything in firefox.
Is there a standard way to download a file through drag and drop, preferably from a url?

Ok, the problem in the example seems to be that Chrome now requires same origin on the DownloadURL.
At least that's what the Firefox developers believe that have had an issue to replicate this feature for 11 years now: https://bugzilla.mozilla.org/show_bug.cgi?id=570164
Safari doesn't seem to support it either

Loading sourcemaps and debugging in Safari?

We ran into an error that only occurs on Safari browsers, so I dusted off my OSX partition on my Macbook and am trying to debug it but I can't find out how to see the original source code and set a breakpoint.
My main file is main.d7f60b0631c7822cabf3.bundle.js and the last line of the file is this, which points to the sourcemap file which does exist because I can type in the url and get it, and it works in firefox and chrome:
//# sourceMappingURL=main.d7f60b0631c7822cabf3.bundle.js.map
In Firefox I can go to the debugger tab in dev tools and under sources I see my original source file webpack:///src/app/app.component.ts and I can open it and set a breakpoint.
In Chrome dev tools I go to the 'Sources' tab and do the same thing navigating a tree to webpack:// - . - src - app - app.component.ts.
Is there a way to achieve the same thing in Safari? From memory since I"m writing this on Windows I can't see any files in the debug tab, just a list of breakpoints. In the resources tab I can see the bundle and an arrow that looks like I should be able to expand it, but clicking on that arrow does turn it from right to down like it is expanded but nothing is displayed. Other files like jquery do seem to have the original source under them when expanded...

I had the same question, and found the answer in another posting here:
How do I toggle source mapping in Safari 7?
(short version, in the debugger, command-click on whatever symbol you want to look at, and it should jump to the original source. For reference, I'm working with TypeScript compiled to JavaScript)
The author points to this documentation:
https://developer.apple.com/library/content/documentation/AppleApplications/Conceptual/Safari_Developer_Guide/ResourcesandtheDOM/ResourcesandtheDOM.html#//apple_ref/doc/uid/TP40007874-CH3-SW4
In the process, I also noticed that in the Resources tab in the Safari debugger, it shows the foo.js with a turner next to it, which expands to show the original foo.ts file (and I assume with a more complex source, it might expand to show multiple sources if they get concatenated together?)
Personal opinion: I think the turner is a great solution to this problem... odd that the debugger defaults to showing the "compiled"/"transpiled" source rather than the stuff one is logically wanting to debug.

First be patient while the browser processes all the source maps.
Whenever that finishes, you should be able to search for any original source file by entering the name of that file into the input field located at the bottom of the pane with the placeholder "Filter". It's a pretty counterintuitive UX IMO. Hope this helps someone!
Screenshot:

Browser specific text-layout bug

A fellow developer and I are on exactly the same Firefox version (41.0.1) using the exact same steps to reproduce a text-layout bug on our web application after hard cache refreshes using the same production server (no local assets), and he sees the bug but I don't. We tried on a 3rd developer's browser (same Firefox version) and he does not see the bug, so it seems isolated to this one browser instance. Both machines are identical - Windows 7 on Lenovo Thinkpad T420. It's a CSS text layout bug - text overflows the box onto multiple lines. I've linked to an image below.
Image of bug here
We have also tried:
Running the problem browser in private browsing mode.
Starting the problem browser in safe-mode (to disable plugins).
Doing a diff between the CSS source file each browser is seeing - they are binary equal
Does anyone have any ideas why this might happen or how else to try to debug it?
Edits:
Other things we have tried:
Reset zoom levels on both (ctrl+0)

Chrome Developer Tools keeps breaking where no breakpoints are set

When debugging JavaScript code using Chrome Developer Tools the debugger pauses on code where breakpoints are not set. I don't have the Pause on exceptions feature enabled, and there definitely are not breakpoints set (see attached image).
I asked a similar question before which was helpful but didn't quite solve this issue (previously I had the Pause on exceptions enabled). In the example below I swapped out the minified version of kendo.all.min.js for the unminified version, which allows me to see where the script execution is being paused, but I don't know why it is being paused. This happens a lot with jquery.min.js too.

I fixed my breakpoints problem by clicking the "Restore defaults and reload" button located in the “Settings” section. To find the button: In Developer Tools click the cogged wheel next to the top right three vertical dots. (Note: If using older versions of Google Chrome, click on the top right three vertical dots and then select “Settings F1”). The button “Restore defaults and reload” is at the bottom right.
Also note that it really restores defaults - you lose all previously saved breakpoints and any files you have open in Developer Tools will be closed.
I got this solution from: Chrome javascript debugger breakpoints don't do anything?

Accepted answer to Import/export Chrome devtools breakpoints & settings between computers reminded me to check "devtools-on-devtools" and in the DevTools' inner Application Local Storage remove the faulty element(s) of the JSON list value for key breakpoints to fix my same issue without resetting everything.
Later it happened again, so I wrote this console snippet:
((stores, matchKey, removeMatchingRegExp, dryRun)=>{for(let store of stores){
let r = JSON.parse(localStorage[store]), l = r.length;
r = r.filter(b=>!b[matchKey].match(removeMatchingRegExp));
if(!dryRun) localStorage[store] = JSON.stringify(r);
console.log(`${dryRun ? 'Would' : 'Did'} remove ${l - r.length} entries from ${store}:`, r)}; return 'OK'})
(['breakpoints', 'domBreakpoints'], 'url',
new RegExp('^https?://example.com/script.js$'), true)
Note:
Provided without warranty: Use at own risk. Backup your data.
Edit it - at least the RegExp argument - to suite your needs.
The last-most boolean should be false to disable dryRun.
Outer DevTools must be reopened for effect.

I was able to resolve this by updating Chrome. I don't think the version matters, just the process of updating resets all of the breakpoints that have been stored in the cache.

F8 has two functionalitys. 1. Skip ot next Breakpoint, 2.stop wherever the Browser is executing code. This works even if you have no breakpoint set. For example spamming F8 when you forgot to deactivate breakpoints might cause the browser to stop anywhere.
When you go to the debugger shortcuts you can see that F8 has the functionality to Pause / Continue. But it sadly seems like you can't split them on two different keybinds.
Since I know this feature I never ran into this "bug" anymore.

I'm posting this answer in case it will help someone who, like me, missed an important clue as to the cause of the phantom breakpoint behavior. In my case, it was "user error" --mine. The root cause was a forgotten "debugger;" statement in a JavaScript file that was itself generated from TypeScript. I had removed the debugger; statement from TypeScript locally, run and tested without issue from localhost. But I had pushed the version with the statement to remote and it built and released to our dev site with the statement present. The dev site build excludes the TypeScript source files. When the debugger statement was hit, Chrome tried to load the .ts source and displayed "Could not load content..." I just assumed it was at a breakpoint (I'd set many during testing). And when I saw "No breakpoint" I assumed Chrome was experiencing the issue addressed in this thread. If I'd bothered to look in the Call Stack trace, I would have seen the source code line in the .ts file and pretty quickly figured it out. Here's a screenshot:

just disable the cache and reload the page, the breakpoints will show up again

HTML5 Drag and Drop styles not displaying on Windows Server 2003

I'm working on a file upload utility based on Valum's Ajax-Uploader. The idea is similar to the Gmail attachment process. The user should be able to drag a file from the desktop into the browser window and onto the file upload area to get it to upload. This works fine in the browsers that support this functionality (Firefox 3.6+, Chrome 7+).
The problem I'm running into are the styles that should be re-drawn when the user:
Drags the file anywhere in the browser
Drags the file into the upload area
I have tested in the exact same browser versions on WinXP, Vista, and Win7. The appropriate styles are redrawn. However, in Windows Server 2003, they do not.
In Win2003, when I inspect the div that should be redrawn via Firebug, the "drop-area" and "drop-area-active" classes are applied correctly. Firebug even shows the correct style declarations, but the changes are never visible.
The only difference between FF and Chrome that I'm able to spot is that in Chrome, the "drop-area-active" style is displayed for a split second when the user drops the file.
I'm not positive that it is a Windows2003 issue, but that's the only OS in which I'm able to recreate the bug.

Edit:
If you're running Win2k3, try the Gmail drag'n'drop functionality. I can see the alternate styles in other OS's, but not Win2k3.
Edit #2:
Still seeing this issue in many different places. Anyone have any suggestions? I have submitted this as a bug to the Chromium Project. Issue 68632.
http://code.google.com/p/chromium/issues/detail?id=68632