1506100 - javascript: protocol URLs typed into the address bar no longer work

Status: NEW

(Firefox :: Address Bar, defect, P3)

Description

[Jonathan Kingston [:jkt] he/him]

Caused by this regression:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=9112406a54a2d3806112111620f25267203a992e&tochange=b5e9fdddf12e598962d6282a4b053aa66b7aabda

Comment 1

[Jonathan Kingston [:jkt] he/him]

Given this is in release and it hasn't caused a huge number of complains should we consider making this a feature? AKA the only way to use javascript: protocol would be through manually adding a bookmark or through web content only.

Comment 2

[:Gijs (out for now; he/him)]

I don't know who makes a decision about this. We made some changes in bug 1018154 to switch to stripping javascript: on paste. That's the last significant deliberate change in our handling of javascript: that I'm aware of. AFAICT it's mostly not been UX making these decisions, even though it's arguably their domain, perhaps because it's such a niche, developer-focused thing, and the main trade-offs are between those developers' desires and security.

In favor of leaving this change in, I'd say that there are a bunch of self-XSS vectors involving JS URIs that feel like whack-a-mole to fix (basically, strip/warn js in various places) and just disallowing it outright except in very very few places is much simpler.

I'm pretty convinced nobody wants to break bookmarklets on web sites, though.

Which means the next question, if we do want to tighten this stuff up, is exactly where we draw the line, and why. Do we only allow js: bookmarklets in the current tab, nothing else? If more, what exactly, and why?

Given this is a regression and it wasn't intentional, my gut sense is we should "fix" this, but before we do that let's ask some of the other folks who have either worked on some of this stuff recently, or used it frequently - and Marco and Mossop, given they're buck-stopper for these parts of the world. :-)

Comment 3

[Boris Zbarsky [:bzbarsky]]

I clearly haven't noticed this being a problem...  I can't actually think of too many use cases for this.  It lacks the convenience of bookmarklets, and the only win over using the console is that opening the console is way too slow, right?

Have we had any external reports of this being a problem for anyone?

I guess this does work in Chrome.  In Safari it does not work by default; you get an error page that says:

  Safari doesn't allow JavaScript from the Smart Search Field

  To allow this, choose "Allow JavaScript from the Smart Search Field" from the Develop menu.

If you select that option you get an "are you sure?" prompt talking about malicious programs harming you.  And you need to enter your OS password.  After that, it works to run scripts, but not to navigate (e.g. javascript:"foo" in the URL bar in Safari does not navigate).

Comment 4

[Dave Townsend [:mossop]]

Yeah I don't particularly think that we should make this work again (though I'm open to it if there is enough consensus). I do think the current behaviour I see (forever loading page) is bad and should be changed to something sane, an error page maybe? Whatever we do we should add a test for the behaviour.

Comment 5

[Rob Wu [:robwu]]

I'm slighly in favor of restoring support for javascript:-URLs in the location bar, because it has some uses and breaking it was not a conscious decision.

The location bar has a few small advantages over the devtools:
- It is faster (no need to wait for devtools to load; also using devtools sometimes slows down the page).
- Bookmarklets may be URL-encoded, and that works fine in the location bar. Not so much in the console.
- javascript:-URLs are not saved in history (devtools commands are saved in the console history).
- It works even if devtools are disabled.

I've seen multiple reports on Reddit about bookmarklets/javascript:-URLs being broken, around the release of 63. E.g. https://www.reddit.com/r/firefox/comments/9qykd0/firefox_63_disabled_javascript_in_address_bar/

Comment 6

[Dave Townsend [:mossop]]

(In reply to Rob Wu [:robwu] from comment #5)
> - Bookmarklets may be URL-encoded, and that works fine in the location bar.
> Not so much in the console.

My understanding was that bookmarklets still work. Is that not the case?

Comment 7

[Boris Zbarsky [:bzbarsky]]

Ah, if there are third-party reports we should consider fixing this.

Comment 8

[Rob Wu [:robwu]]

(In reply to Dave Townsend [:mossop] (he/him) from comment #6)
> (In reply to Rob Wu [:robwu] from comment #5)
> > - Bookmarklets may be URL-encoded, and that works fine in the location bar.
> > Not so much in the console.
> 
> My understanding was that bookmarklets still work. Is that not the case?

By "Bookmarklets", I meant "javascript:"-URL strings.
Bookmarks do work (in the current tab, not in new tabs - bug 1502072).

Comment 9

[Marco Bonardo [:mak]]

(In reply to Boris Zbarsky [:bzbarsky, bz on IRC] from comment #3)
> I guess this does work in Chrome.  In Safari it does not work by default;
> you get an error page that says:
> 
>   Safari doesn't allow JavaScript from the Smart Search Field
> 
>   To allow this, choose "Allow JavaScript from the Smart Search Field" from
> the Develop menu.

I like this approach, developers could have a new pref that can be flipped through the devtools options panel, and get the full Address Bar javascript functionality:
 * typed urls would work
 * we could stop stripping javascript: on paste
 * we could remove browser.urlbar.filter.javascript and just rely on this new pref

Adding an error page may be a bit more work though, and it could end up being a footgun, telling a non-technical user "the url you typed doesn't work unless you set this option" may path the way to reopening security issues (users may do what is suggested without fully understanding the consequences).

Though, it really depends on consensus, I'd be open to this approach.

Comment 10

[Marco Bonardo [:mak]]

we have one new case in bug 1552141, where a bookmark keyword points to a bookmarklet, and because of this bug it wouldn't work (modulo the fact we currently wrongly filter out that result).

This needs a decision, to either take the devtools path (a single pref to control the js in urlbar behavior) or we decide that we don't support the case, and then bug 1552141 becomes a wontfix, in the sense we won't support keywords replacement in bookmarklets.

Comment 11

[Dave Townsend [:mossop]]

Not sure who makes the call here, what does product think?

Comment 12

[Andreas Bovens [:abovens]]

I think I'd be fine with not having javascript: support in the address bar, not even via a special devtools pref — there are very few use cases not solved by bookmarklets or the console.

Looping in Mike, Harald and Martin for their take.

Comment 13

[:Harald Kirschner :digitarald]

I am also not aware of any use cases. If users want to execute snippets, Console works just fine and now even better with the multiline editor mode. Given how little feedback that thread has gotten from outside, it seems save to remove.

Comment 14

[Martin Balfanz [:mbalfanz]]

No objections here and I'm not aware of more use cases than already mentioned. So, as long as bookmarklets work I think we're good to remove it.

Comment 15

[Mike Conca [:mconca]]

I also agree with the removal of this feature.

Comment 16

[:Gijs (out for now; he/him)]

Sounds like there's consensus to remove this feature ie to keep this broken.

Is there anything left to do here? Perhaps there's code that can be removed, like the code that strips the javascript: protocol from pastes? Or other JS-specific urlbar code? Perhaps we want to show an error page instead of doing nothing (which is the current behaviour) ?

Comment 17

[Dave Townsend [:mossop]]

I would vote for an error page and ideally an automated test.

Comment 18

[Jonathan Kingston [:jkt] he/him]

Attachment: Bug 1506100 - Prevent JavaScript load in system principal context when we are not permitted to inherit principal.

Comment 19

[Jonathan Kingston [:jkt] he/him]

So the attached patch prevents and user initiated UI loading of a javascript: url and loads an error page. This prevents mayInheritPrincipal=false && isSystemPrincipal and nothing else. So a content page can still load javascript urls and also bookmarks who inherit principals can load javascript.

Comment 20

[majkinetor]

Removal of this feature is totally unapropriate.

It blocks certain kind of browser automation that is used quite a lot in certain circles. For example, in Autohotkey scripts this is often used method to influence pages displayed externally without any programming ceremony, by simply CTRL + L + Send(keys).

Furthermore, what is the point of browser.urlbar.filter.javascript option ?

You can do this in all other browsers, and this defect alone made me return to Chrome for certain work until it gets fixed.

So please, you didn't thought this trough, fix the issue, it is already disabled by default, whats the harm ?

Comment 21

[:Gijs (out for now; he/him)]

(In reply to majkinetor from comment #20)

It blocks certain kind of browser automation that is used quite a lot in certain circles. For example, in Autohotkey scripts this is often used method to influence pages displayed externally without any programming ceremony, by simply CTRL + L + Send(keys).

You could do exactly the same thing by using the console shortcut (ctrl-shift-k) and then whatever you were posting in the URL bar, without the javascript: bit (you can close it again with ctrl-shift-i). Is there some reason that doesn't work?

Also, when you say "circles", what "circles" are these? Is there a vibrant community of people who write autohotkey scripts that then manipulate in-browser documents that you can link us to?

Furthermore, what is the point of browser.urlbar.filter.javascript option ?

Whether or not bookmarklets / history entries for javascript: URIs show up in the autocomplete results; this preference doesn't govern what happens if you try to navigate to javascript: URIs yourself.

You can do this in all other browsers, and this defect alone made me return to Chrome for certain work until it gets fixed.

We first (accidentally) broke this in a copy of Firefox released 11 months ago (Fx63, released october 2018), but as far as I know nobody reported it broken until now (except, in this report, the developer who broke it). What changed?

It is already disabled by default, whats the harm ?

It's not "already disabled" (which implies there's some pref to turn it on/off), it's broken, and it's been broken in shipping release versions of Firefox for nearly a year, as far as I know without any complaints before yours just now. So rather than leaving it in a broken state we're adding an error page to say "you can't do this", and tests so that we notice if anything about this behaviour changes by accident in the future.

Comment 22

[majkinetor]

You could do exactly the same thing by using the console shortcut (ctrl-shift-k) and then whatever you were posting in the URL bar

Not exactly the same thing. Using URL bar is almost invisible, while opening and closing console between any action is totally unapropriate.

Also, when you say "circles", what "circles" are these? Is there a vibrant community of people who write autohotkey scripts that then manipulate in-browser documents that you can link us to?

When I say circles I mean its a common technique. For example, few quick finds:

• https://www.autohotkey.com/boards/viewtopic.php?f=76&t=67687&p=290936#p290936
• https://autohotkey.com/board/topic/874-using-javascript-in-ahk-script-to-control-web-pages
• https://stackoverflow.com/questions/45846797/how-can-i-execute-javascript-methods-with-autohotkey

Whether or not bookmarklets / history entries for javascript: URIs show up in the autocomplete results; this preference doesn't govern what happens if you try to navigate to javascript: URIs yourself.

OK, thanks, it seems that bunch of people on the Internet are mistaking this one for another thing.

Nobody reported it broken until now

Given the global usage of Firefox and specific niche this falls into, I am not really surprised. In my case, I noticed this first day it occured. I was trying intermitiently to make it work thinking that this is some config issue. Then I switched to Chrome. Now I am using FIrefox again, and thought to check it out again and do a bit more investigation as I want to stay on Firefox. I am sure not many people find this thing show stopping .

So rather than leaving it in a broken state we're adding an error page to say "you can't do this", and tests so that we notice if anything about this behaviour changes by accident in the future.

You are still leaving it broken, you just made a ceremony around it and promoted it into a 'feature'. I am confused why this isn't actually made into advanced feature if you are concerend about security.

Comment 23

[Brad Waite]

I'd like to take a quick moment and add my voice to majkinetor's. I use javascript: from the address bar thousands of times a day in my business, usually in conjunction with AutoHotKey. I was about to complain when this first broke, but then I discovered ESR, and was happily running that until the most recent update.

The console is slower and requires a focus change to deal with the separate window, or change how the window is parsed when accessing in-browser objects directly through COM + MS's Accesibility.

I would humbly request that this be fixed, and if security is a concern, disable it by default but give users the ability to enable it

Comment 24

[Jake]

Any ETA on fixing this bug?

Comment 25

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months.
:adw, could you have a look please?
For more information, please visit auto_nag documentation.