Closed Bug 728313 Opened 12 years ago Closed 6 years ago

Bookmarklet fails on about:newtab

Categories

(Firefox :: New Tab Page, defect)

defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: bzbarsky, Unassigned)

References

Details

(Keywords: parity-chrome)

Attachments

(1 file)

Build: anything with bug 723808 fixed.

Steps to reproducs:

1)  Follow instructions at http://lifehacker.com/240552/firefox-tip--how-to-set-up-multi+parameter-keyword-searches

2)  Hit Cmd-N

3)  Type in the bookmark keyword for the bookmark in step 1

ACTUAL RESULTS: JS doesn't run, since it has no principal to do so with

EXPECTED RESULTS: Make it work.

The problem is that about:newtab is system-principal, and we're trying to run the JS against it.

Perhaps we should consider replacing system-principal pages with about:blank before loading javascript: URIs?
(In reply to Boris Zbarsky (:bz) from comment #0)
> Perhaps we should consider replacing system-principal pages with about:blank
> before loading javascript: URIs?

This would be ideal (for more than just this bug), but I was under the impression that it was kind of hard. Or did you mean a front-end fix?
Does just calling CreateAboutBlankContentViewer() not do the right thing?
Attached patch attempt #1Splinter Review
I'm not confident this patch is suitable to land, but it's a quick hack to test whether this approach would work. It doesn't seem to work (the new tab page stays loaded and the JS doesn't run), but I don't really know why.
> Perhaps we should consider replacing system-principal pages with about:blank before 
> loading javascript: URIs?

Another possibility would be to use disallowInheritPrincipal.  Then clicking a bookmarklet on about:newtab would be equivalent to typing a javascript: URL into the address bar (on any page).

Problem is, "location=" and "location.replace" don't seem to work with disallowInheritPrincipal.
Summary: Using a bookmark keyword to a bookmarklet fails on new tabs → Bookmarklet fails on about:newtab
OS: Mac OS X → All
Workaround: Change the new tab page as described here https://support.mozilla.org/en-US/kb/new-tab-page-show-hide-and-customize-top-sites#w_how-do-i-turn-the-new-tab-page-off

Setting it to e.g. about:blank makes the bookmarklets work again. This is obviously only viable if you think it's acceptable to get a blank page when opening a new tab.
Mass-move to Firefox::New Tab Page.

Filter on new-tab-page-component.
Component: General → New Tab Page
Now that browser.newtab.url has been disabled, imo, this is a great annoiance.
You should probably just install https://addons.mozilla.org/en-US/firefox/addon/new-tab-override/ for now like I just did, pending bug 776477 getting fixed.
Thanks a lot Boris, this add-on is what I want, perfect :-)
Hardware: x86 → All
Whiteboard: [parity-chrome]
Neither this bug nor bug 776477 has had any relevant activity, but I am able to use bookmarklets on about:newtab in Nightly now. No idea what the relevant bug is.
Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)
Keywords: parity-chrome
Whiteboard: [parity-chrome]
This was resolved by the switch to activity-stream, I think.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: