417824 - Feature change in Bug 412862 stops Bookmarklets that resize windows from working.

Status: RESOLVED WONTFIX

(Firefox :: General, defect)

Description

[Michael P. McHugh]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12

Just trying out the 3 beta 3 and discovered this new white-listing behavior for the 'allow scripts to move or resize existing windows' pref,which is fine, but it prevents one's own 'bookmarklets' that resize and reposition windows to stop working.

These bookmarklets are indispensable for web development and just organizing one's own windows. Here's an example of one:

javascript:self.resizeTo(1064,1094);self.moveTo(459,0);

Though I don't disagree with the new white listing feature, it should probably be a user options, or there needs to be some way of white-listing these local bookmarklets, or a check box to allow them to work.

-Michael

Reproducible: Always

Steps to Reproduce:
1. Create or drag a bookmarklet like (javascript:self.resizeTo(1064,1094);self.moveTo(459,0);) to the bookmarks bar.
2. Click it.
3. It does not work.
Actual Results:  
Bookmarklets that resize or reposition windows no longer work

Expected Results:  
Bookmarklets that resize or reposition windows should work, as they are not from external URLs

Comment 1

[philippe (part-time)]

That pref is user configurable: Preferences > Content, next to 'Enable Javascript', there is a big button to access those settings.

Comment 2

[Michael P. McHugh]

But it's not configurable enough to allow local bookmarklets to function. All you can do is add white-listed domains.

Comment 3

[Johnny Stenback (:jst)]

Local bookmarklets run in the context of the current page, with the security principal of the current page. There's no easy way to treat them differently from other JS :(

Comment 4

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Michael, if that's the case then all you have to do is whitelist the sites that you're going to use those bookmarklets on. A pain, I guess, but at least you can get it working.

Comment 5

[Michael P. McHugh]

What if you have blank window? What security principle is used then?

This all might argue for reinstating a checkbox to turn the whole feature on or
off as before, but keeping the whitelist for when it it checked. At least that
would not be a reduction of functionality like it is now.

I like the whitelist concept, but it seems to be a huge change to take the user
preference away on this one, without some consideration of local scripting.

I use the bookmarklets routinely to go full screen and back to a pre-determined size and position, but also use others to resize to see pages in smaller windows for development purposes.

So, whitelisting all needed pages is not realistic at all, especially since it's not easily doable on the fly, and only via the 2nd level down prefs window.

Comment 6

[Johnny Stenback (:jst)]

(In reply to comment #5)
> What if you have blank window? What security principle is used then?

about:blank, or really an internal unique principal we create for each about:blank document.

> This all might argue for reinstating a checkbox to turn the whole feature on or
> off as before, but keeping the whitelist for when it it checked. At least that
> would not be a reduction of functionality like it is now.

The problem with that is that enabling that globally is a security risk we're not willing to take. You can still do that yourself using about:config, if you really want to. But we won't be adding UI for that pref.

[...]
> So, whitelisting all needed pages is not realistic at all, especially since
> it's not easily doable on the fly, and only via the 2nd level down prefs
> window.

Then I would recommend you use about:config to enable the old behavior in a profile you use for development only, and leave it off for normal browsing.

Comment 7

[Michael P. McHugh]

Well, whether or not it's done for an initial 3.0 release or later, some other user configurable workaround should be explored — some way of treating local bookmarklets differently than the page content, which seems to make sense, since they are not page content.

Using a separate profile for development is not realistic for most people, as it's a major inconvenience, imo.

In the interim, I would just turn it off via about:config and live with the security risk, as anything else suggested is just not worth the effort, and seems to be more of an annoyance than a security risk anyway.

I wouldn't be surprised if there's a lot of push back on this once it's released as such bookmarklets are very common, especially amongst web designers and developers, and have been widely disseminated. To have them all suddenly stop working will not go unnoticed.

I still think removing such functionality is a bad idea, even in the name of security, without some sort of viable workaround or choice in the matter. Leaving the only viable option buried in about:config is not very user friendly.

Eventually somehow treating bookmarklets differently than page-based javascript seems to be the best route for the long term.

Comment 8

[Jesse Ruderman]

Giving bookmarklets additional powers while still having them execute in the context of the page would be very difficult.  Doing so without introducing security holes may be impossible.  Requests to let bookmarklets do additional things come up every once in a while and the answer is always "no".

What you can do is whitelist a specific site and navigate to that site before using the window-resizing bookmarklet.  You can even hack the bookmarklet to take you to that site if it isn't there already, and take you back after resizing the window.

Or, you can write an extension for resizing windows, and use the extension instead of a set of bookmarklets.