javascript url bookmarks don't run if opened in new tab

RESOLVED FIXED in Firefox 67

Status

()

defect
P2
normal
RESOLVED FIXED
7 months ago
2 months ago

People

(Reporter: omgitsraven, Assigned: jkt)

Tracking

({regression})

63 Branch
Firefox 67
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox-esr60 unaffected, firefox63 wontfix, firefox64 wontfix, firefox65 wontfix, firefox66 wontfix, firefox67 fixed)

Details

Attachments

(1 attachment)

Reporter

Description

7 months ago
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:63.0) Gecko/20100101 Firefox/63.0

Steps to reproduce:

Make a bookmark to a javascript: url, then right-click it and do "open in a new tab".


Actual results:

A blank tab opens, with the javascript in its address bar, but the script does not run.


Expected results:

It should behave the same as it does if the bookmark were just left-clicked on, i.e. the script should run.
Comment hidden (obsolete)
Reporter

Comment 2

7 months ago
The opposite of that, actually -- they were saying that their bookmarklet would ONLY work if you do 'open in new tab' in the context menu. I'm saying it only works if you DON'T.
Please ignore my last comment, that was an old bug but this is a recent regression.


2018-10-26T01:28:44: DEBUG : Found commit message:
Bug 1466801 - Flipping disallowInheritPrincipal to be allow. r=ckerschb r=gijs

2018-10-26T01:28:44: DEBUG : Did not find a branch, checking all integration branches
2018-10-26T01:28:44: INFO : The bisection is done.


This looks like a intentional change
Status: UNCONFIRMED → NEW
Component: Untriaged → General
Depends on: 1466801
Ever confirmed: true
Flags: needinfo?(jkt)
Keywords: regression
Reporter

Comment 4

7 months ago
I definitely saw the recent stuff about changing what permissions javascript urls have, and I assume that it came about as a *result* of that, but I'm not sure whether this particular aspect of it could be intentional? What would the rationale be behind "running a bookmarklet in an existing tab is fine, running it in a new one isn't"? (If it were a security concern, I'd expect it to be the other way around…)

Updated

7 months ago
See Also: → 1484741
Assignee

Comment 5

7 months ago
I'm pretty sure this is a duplicate of Bug 1484741 which isn't in 63 but is riding the trains instead.
Flags: needinfo?(jkt)

Comment 6

7 months ago
(In reply to Jonathan Kingston [:jkt] from comment #5)
> I'm pretty sure this is a duplicate of Bug 1484741 which isn't in 63 but is
> riding the trains instead.

I thought that, but the STR in this bug involve the context menu on bookmarks, and your fix in that bug only touches urlbarbindings.xml, so I think a separate fix would be required. Did the context menu case get fixed elsewhere?
Flags: needinfo?(jkt)
Reporter

Comment 7

7 months ago
Also, just to be as specific as possible, I might as well mention, it also doesn't work when middle-clicking the bookmark (which does the same thing as 'open in new tab').
I have tested this bug with the latest nightly before confirming this report and this is not fixed by bug 1484641.

Middle mouse button click or context menu->open in new tab doesn't work after the checkin from bug 1466801
It works if you use the context menu to open the bookmarklet in a new window instead of a new tab.

Comment 9

7 months ago
This is a regression and ideally we should fix for 64, though js: bookmarks are a bit of an edgecase and opening them in separate tabs even more so. Going to move to Fx::Bookmarks and Marco & co can decide on priority.

:jkt, any idea what's going on here and why we didn't catch this before release?
Component: General → Bookmarks & History
Priority: -- → P2
Assignee

Comment 10

6 months ago
Pretty sure I know how to fix this, I'll take a look later.
Assignee: nobody → jkt
Flags: needinfo?(jkt)
Assignee

Updated

6 months ago
See Also: → 1506100

Jonathan, do you plans to work on fixing this bug for 67 or should we move that bug to the backlog (P3)? Thanks

Flags: needinfo?(jkt)
Assignee

Comment 13

3 months ago

:gijs sorry for the delay here. I think we should just permit this to all 'aWhere' targets. I think it's safe to uplift too.

Flags: needinfo?(jkt) → needinfo?(gijskruitbosch+bugs)

Comment 14

3 months ago
Pushed by jkingston@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/b14084271877
Removing restriction of opening javascript places into new tabs. r=Gijs

Updated

3 months ago
Flags: needinfo?(gijskruitbosch+bugs)

Comment 15

3 months ago
bugherder
Status: NEW → RESOLVED
Last Resolved: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 67
Blocks: 1466801
No longer depends on: 1466801
QA Whiteboard: [qa-67b-p2]
You need to log in before you can comment on or make changes to this bug.