In desktop Firefox, javascript: urls will not be run from the awesome bar - regardless of whether they are pasted or typed. See bug 656433 which made this change. In Fennec, both birch and XUL versions, javascript: URL's are executed, whether copied or pasted. I would like to state up front that this is a contentious issue on desktop - see bug 527530 for some background of the pros and cons and bug 680302 for adding a pref to allow users to control this behavior or not - adding a pref lets advanced users/developers opt in while protecting the majority of users who don't have a real need to run arbitrary JS. Other browsers have adopted partial mitigations for this issue, while not being as strict as Firefox - this has led to attackers modifying their social engineering approach to be along the lines of "type j and then paste this : avascript:<evil script> into your address bar" to work around incomplete defenses. this vector is being used in the wild currently to flood Facebook with spam of various kinds, see http://www.huffingtonpost.com/2011/11/15/facebook-spam-attack-photo_n_1095938.html and http://mashable.com/2011/11/15/facebook-spam-porn/ a statement from Facebook from the mashable story : "During this spam attack users were tricked into pasting and executing malicious javascript in their browser URL bar causing them to unknowingly share this offensive content. " some users have objected to the mitigation of this problem on desktop, because it breaks some of their use cases - the usual response there is 'use the scratchpad/console' - but there is no console/scratchpad equivalent in Fennec at the current time. One stated use case is usually along the lines of developers testing sites via hand entered javascript. Mobile is different from desktop however - typing on mobile is much more painful and convincing users to type in long script strings seems a little unlikely. Pasting is probably a more valid concern. That said, on mobile many users will be accessing sites such as Facebook via an app and the barrier to getting them to fire up the browser, log in to a site in the browser and then paste some malicious JS may be quite a bit higher. It is worth noting that the stock browsers I tried on Android 2.x and 3.x also exhibit this behavior. It is probably worth testing other popular mobile browsers to see how they behave here (eg Mobile Safari, Dolphin, etc.). On one hand nobody implementing it could be a sign this isn't widely considered a problem on mobile - on the other, it could be an opportunity for Fennec to continue pushing a secure mobile browsing experience ahead of the curve.

also it's worth considering that this may be a lot more feasible on tablets than phones - that's just a gut instinct of mine though.

This is also not blocked in * iOS 5.0.1 * Dolphin 7.1.0 * Android Browser {Galaxy Tab 10.1 (has an option for javascript that is on by default, when unchecked this does not work) tested with javascript:('lol');

(In reply to Curtis Koenig [:curtisk] from comment #2) > tested with javascript:('lol'); should read javascript:alert('lol');

this also is not blocked in the current Opera Mobile on Android

(In reply to Ian Melven :imelven from comment #0) > In desktop Firefox, javascript: urls will not be run from the awesome bar - Just a note of clarification: they will run, but they will not inherit the principal of the current page (and won't run in a DOM context, so will throw if they attempt to reference window./document./etc.). javascript:1+1 still works fine.

Comment on attachment 581881 [details] [diff] [review] patch I'd rather push this to browser.js and use the Ci.nsIWebNavigation.LOAD_FLAGS_DISALLOW_INHERIT_OWNER flag. I can take this since the change is in JS

(In reply to Mark Finkle (:mfinkle) from comment #7) > Comment on attachment 581881 [details] [diff] [review] > patch > > I'd rather push this to browser.js and use the > Ci.nsIWebNavigation.LOAD_FLAGS_DISALLOW_INHERIT_OWNER flag. my fist cut at a patch did that, but it didn't work > > I can take this since the change is in JS have at it

This patch moves the checks into browser.js and follows the method used in bug 656433 for desktop Firefox. * Refactors code so that all URI loading is handled via BrowserApp.loadURI or Tab.create * Adds LOAD_FLAGS_DISALLOW_INHERIT_OWNER flags to the Tab:Add and Tab:Load handlers - which are the two ways something from the URLBar is loaded into a browser. * Adds a Content:LoadError message and handler to Java so we can reset the URLbar if a bad load happens (about:homer for instance). Bad loads can start the throbber and change the title display, so we reset them. * GeckoApp.loadRequest was starting the throbber to get it moving ASAP instead of waiting for handleDocumentStart to do it. This was causing problems where we had no way of stopping the throbber. We now wait for handleDocumentStart, which has a barely noticeable delay. Bug 709497 will fix that.

Comment on attachment 582272 [details] [diff] [review] alt patch >+ try { >+ this.browser.loadURIWithFlags(aURL, flags, referrerURI, charset, postData); >+ } catch (e) { >+ let message = { >+ gecko: { >+ type: "Content:LoadError", >+ tabID: this.id, >+ uri: this.browser.currentURI.spec, >+ title: this.browser.contentTitle >+ } >+ }; >+ sendMessageToJava(message); >+ } Let's log the exception to the console here too, for help with future debugging.

added logging https://hg.mozilla.org/integration/mozilla-inbound/rev/f467bd6781a1

I am not sure if the following case is related to this bug or not. I loaded in a new tab javascript:('lol') and the string was displayed in the new opened page. I closed the tab and about:home (which was default loaded) was on the screen. I tapped on URL Bar for Awesomesbar and the javascript:('lol') was listed there, but if I tap on it, Fennec will just switch to about:home. Also the thumbnail of javascript: page is listed on about:home, but if I tap on it, the throbber starts spinning without opening that javascript: page. And it seems that will stay like that forever. However, the javascript: page can be opened from history only if a new tab is opened. Is this expected? -- Firefox 13.0a1 (2012-03-04) Device: HTC Desire OS: Android 2.2

(In reply to Cristian Nicolae (:xti) from comment #13) > I am not sure if the following case is related to this bug or not. > > I loaded in a new tab javascript:('lol') and the string was displayed in the > new opened page. I closed the tab and about:home (which was default loaded) > was on the screen. I tapped on URL Bar for Awesomesbar and the > javascript:('lol') was listed there, but if I tap on it, Fennec will just > switch to about:home. > > Also the thumbnail of javascript: page is listed on about:home, but if I tap > on it, the throbber starts spinning without opening that javascript: page. > And it seems that will stay like that forever. > > However, the javascript: page can be opened from history only if a new tab > is opened. Is this expected? This sounds like a bug that we're saving the javascript: URL in history when we shouldn't. We should probably avoid storing URLs in history if they fail to load properly. Could you file a new bug?

(In reply to Margaret Leibovic [:margaret] from comment #14) > > This sounds like a bug that we're saving the javascript: URL in history when > we shouldn't. We should probably avoid storing URLs in history if they fail > to load properly. Could you file a new bug? Sure. I will file one. Then this bug could be closed as verified fixed

Bug 733327 was filled