context-menu does not work well on Facebook



7 years ago
7 years ago


(Reporter: KWierso, Unassigned)


Windows 7

Firefox Tracking Flags

(Not tracked)





7 years ago
I wrote this addon to help someone on IRC use context-menu. When you install it, rightclicking on any link on Facebook *should* show my new context menu item, which logs the link's URL to the console when clicked.

This works fine if you're on the first page-load on Facebook. But if you click a link to someone's Wall or photo section, the context menu item doesn't appear until you do a hard refresh of the page.

So I guess whatever AJAXy voodoo that Facebook does to load the new pages into the current page doesn't trigger Jetpack to see what items need context menu items added?

Comment 1

7 years ago
Could I see the add-on?

Comment 2

7 years ago
Oh yeah, that might help.\


Comment 3

7 years ago
Oddly, if I change the SelectorContext to be *, it works on the subsequent pages...

Comment 4

7 years ago
Thanks.  Yeah, I was just about to say, does using a SelectorContext of  "*" work?  "*" would only match pages whose URLs have that exact prefix, so it wouldn't match http or subdomains.

Comment 5

7 years ago
Er, URLContext.  Another problem may be that the things that look like links aren't actually anchors but clickable spans or divs or something.

Comment 6

7 years ago
All of the pages that I'm clicking on stay in the* area.

Firebug says all the ones I'm trying are anchors.

Comment 7

7 years ago
Are you sure they're anchors that match the selector in the add-on, a[href], i.e., that they have href attributes?

Comment 8

7 years ago
Yes, I'm sure. I'll give it a try with just "a" later tonight to see if that changes anything.

Comment 9

7 years ago
I tried the add-on.  I noticed if I start on my own profile page at https and I click on someone else's name, I'm taken to their profile page -- but at http.  And I stay on http when I check their photos and wall until I manually edit the URL in the URL bar to be https.  Even if I log in from, I'm redirected to http.

When I change the URLContext to be "*", the item appears as expected.

Wes, can you confirm that this is the problem?

Comment 10

7 years ago
For me, the HTTPS stays present at all times (until/unless I try to use some app that doesn't support HTTPS, then I get dropped back to HTTP). I have the Facebook setting for "Secure Browsing (https)" turned on, so it always prefers https for me. (On a side note, the documentation for match-pattern doesn't show that "*.domain.tld" works for anything other than http, so https wouldn't work at all...)

I still haven't had a chance to play with the SelectorContext thing.

Comment 11

7 years ago
(In reply to comment #10)
> prefers https for me. (On a side note, the documentation for match-pattern
> doesn't show that "*.domain.tld" works for anything other than http, so
> https wouldn't work at all...)

It works for any scheme.  I filed bug 656467 to clarify that.

I flipped the setting you mentioned and now I'm not able to reproduce at all.  If you could tell me the exact bits of Facebook UI that don't work properly it would be a big help.  Screenshots might do that best.
Whiteboard: [triage:followup]
Is there any more info about the problem?  It's not clear from the conversation to date how significant this problem is.

Comment 13

7 years ago
Hi - I'm having a similar problem with my attempt at an addon, so I've created the following to see what's going on.. it seems like iFrames may be causing issues... here's what I did:

1) My addon would only run the first time I hit a page matching the ruleset, so I tried to console.log(location.href) and noticed that only ad units (being served via iframes) triggered a console.log .. yikes!

2) I then stretched out my include match to just be * .. this shows, I'm pretty sure, that iFrames cause Jetpack headaches...  

Here's my code...


// Import the APIs we need.
var pageMod = require("page-mod");
var self = require("self");
  include: ["*"],
  contentScriptWhen: 'ready',


If you do this, and then visit you'll see two log entries:


Now click any link from to another page on in this case I'll click a comments link.. I see:


Note no presence of the URL I'm visiting, which is

Now we try another site - -- oddly, never shows up in console.log.  Instead, the only things showing up in console.log are long URLs that clearly seem to be from iFrames / ad units:

info:[parameters removed for brevity]
info:[parameters removed for brevity]
info:[parameters removed for brevity]
info:[parameters removed for brevity]
info:[parameters removed for brevity]

Hope this helps...

Comment 14

7 years ago
(In reply to comment #13)
It might not be quite the same thing that this bug is about (a quick glance at Facebook's code doesn't show any iframes), but they both have similar problems of non-typical page loads not getting registered by the SDK code.

Comment 15

7 years ago
Yep, i posted it here based on our convo on IRC but on further reading it may be a bit different... do you think I should post a separate bug report?

I wouldn't call the page loads in my description "non-typical" at all though... I'd say it's the non-typical ones getting through, and the typical ones not :-\

Comment 16

7 years ago
Yeah, a separate bug would probably be best. Then when either one gets a fix, we can test the other one and see if the same thing fixed it. (Plus, if it isn't the same issue, less confusion in this bug about problems completely unrelated to this one. :) )

Comment 17

7 years ago
It's not clear to me that this bug has to do with page loads nontypical or otherwise.  Actually it's not clear to me that there is any bug here at all.

Comment 18

7 years ago
Okay, I changed the test addon a little:

It now runs on "*" and targets any <a> element, whether it has an href attribute or not.

Builder still only has 1.0b4 up there, so maybe this is fixed in b5 or later? My development environment is screwed up at the moment, so I can't try this out in newer code without fixing that first.

This is a screen capture video of the issue in a brand new Firefox profile with only the test addon installed. Hopefully it's self-explanatory what it's showing.

Comment 19

7 years ago
Thanks for taking the time and effort to make the screencast.  I really appreciate it.

OK, I didn't realize Builder was still at 1.0b4.  I can reproduce when I try with b4, including the "window key is not in registry" errors I see in your video.  I can't reproduce in b5.  I rewrote a bunch of stuff in b5, which fixed other bugs, so it's not surprising that the two versions behave differently.

I'll leave this bug open until either you confirm that you also can't reproduce on b5 or some time passes and I don't hear back from you.  Thanks again.

Hopefully this will teach me to really use the Builder when the bug reporter used the Builder, and to always keep in mind which version of the SDK the reporter used.
It seems like this is going to be worksforme, so P2/futuring to get it off drivers' radar, but if it turns out that it still exists, then please clear that priority/target milestone to get it back on our radar!
Priority: -- → P2
Whiteboard: [triage:followup]
Target Milestone: --- → Future

Comment 21

7 years ago
Marking WFM per comment 19.  Please re-open if you can still reproduce on 1.0b5 or later.
Last Resolved: 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.