Fix #10786 - Allow QuickView image preview for arbitrary URLs

[humphd]

This leverages the img element's load and error events to try and load arbitrary images. It also expands the list of known image extensions to include .bmp, which browsers can display.

[humphd]

I've updated this with the suggestion made to examine extensions.

[marcelgerber]

Could you take a look at the data provided by language.json/LanguageManager and see if you can use them? image is particularly interesting for whitelist (please concat "svg" yourself), audio and binary for blacklist (concat the ones you already have, plus maybe also "rss", "php").

[humphd]

I've rewritten this to use LanguageManager, good suggestion.

[humphd]

This is ready for review.

[nethip]

@humphd Can you add some unit tests, if possible? Also run smoke tests with these changes, especially the one relating to editor and Extensions.

[nethip]

Could you put in the imgPath check here?

[humphd]

It's already been dealt with in the if-block above from lines 475-483, returning early if we have no value for imgPath, and therefore not needing to do the check and indent all this code.

[nethip]

LGTM

[redmunds]

The original Quick View implementation had support for arbitrary URLs, but it was removed due to concerns about performance (i.e. downloading external files on mousemove!). The code has been optimized since then so it now does not try to parse code in editor until mouse hasn't moved for 350ms, but people with a slow network or no network connection might see problems.

Be sure to test this with no internet connection!

You should consider:

1. Making this a preference. It's probably OK to default to ON as long as there's a way to turn it OFF.
2. Caching images. No need to re-download same image over and over. Maybe this already takes advantage of browser cache. Then there's the opposite problem of a stale cache :)

[humphd]

I've updated this again. New commit adds:

• pref for enabling/disabling extensionless previews for URLs (on by default). Let me know if this is how you want such a pref to be done.
• tests for everything that seemed obvious to me about what this patch is doing.

Regarding @redmunds' questions. First, with no network, you end up in the error path (net::ERR_INTERNET_DISCONNECTED exception or the like trying to load the resource) and it does the right thing. I think cache is best handled by the browser. Trying to build something more intelligent than what is already there for free seems like a waste of effort to me.

[redmunds]

Should never write to prefs on initial load. This is unnecessary and slows down startup. I can see that this is emulating the other pref here, so remove that also if possible.

[redmunds]

Actually, call to setEnabled(prefs.get("enabled"), true); on line above is not writing to prefs, so that should be ok.

[humphd]

So the whole doNotSave dance was done for the initial load case? I'll echo that for this as well and avoid the write.

[redmunds]

In general, this looks good. Be sure to turn on JSLint as I am seeing some JSLint errors in QuickView/main.js. Also, there is a merge conflict that needs to be resolved. Just 1 other comment.

[humphd]

@redmunds thanks for the review. I've rebased and pushed fixes. See if this approach satisfies what you wanted with the pref saving and startup.

[redmunds]

@humphd

See if this approach satisfies what you wanted with the pref saving and startup.

Looks good.

[humphd]

Great, can someone land this then?

[nethip]

Thanks @humphd for this fix