Closed Bug 656143 Opened 13 years ago Closed 13 years ago

context-menu does not work well on Facebook

Categories

(Add-on SDK Graveyard :: General, defect, P2)

Product:
Add-on SDK Graveyard
Component:
General
Platform:
x86
Windows 7
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME
Milestone:
Future

People

(Reporter: KWierso, Unassigned)

References

(
URL
)

Details

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?
Could I see the add-on?
Oddly, if I change the SelectorContext to be *, it works on the subsequent pages...
Thanks.  Yeah, I was just about to say, does using a SelectorContext of  "*.facebook.com" work?  "https://www.facebook.com/*" would only match pages whose URLs have that exact prefix, so it wouldn't match http or subdomains.
Er, URLContext.  Another problem may be that the things that look like links aren't actually anchors but clickable spans or divs or something.
All of the pages that I'm clicking on stay in the https://www.facebook.com/* area.

Firebug says all the ones I'm trying are anchors.
Are you sure they're anchors that match the selector in the add-on, a[href], i.e., that they have href attributes?
Yes, I'm sure. I'll give it a try with just "a" later tonight to see if that changes anything.
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 https://www.facebook.com/, I'm redirected to http.

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

Wes, can you confirm that this is the problem?
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.
(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.
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...

lib/main.js:

// Import the APIs we need.
var pageMod = require("page-mod");
var self = require("self");
pageMod.PageMod({
  include: ["*"],
  contentScriptWhen: 'ready',
  contentScriptFile: self.data.url('test.js')
});



data/test.js:
console.log(location.href);


If you do this, and then visit http://www.reddit.com/ you'll see two log entries:

- http://www.reddit.com
- http://www.redditmedia.com/ads/

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

- http://www.redditmedia.com/ads/r/pics

Note no presence of the URL I'm visiting, which is http://www.reddit.com/r/pics/comments/hkydf/lord_of_the_rings_revision/


Now we try another site - http://slickdeals.net -- oddly, http://slickdeals.net 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: http://204.93.181.78/sd/dmsd.html
info: http://pubads.g.doubleclick.net/gampad/ads?[parameters removed for brevity]
info: http://static.ak.fbcdn.net/connect/xd_proxy.php?[parameters removed for brevity]
info: http://pubads.g.doubleclick.net/gampad/ads?[parameters removed for brevity]
info: http://pubads.g.doubleclick.net/gampad/ads?[parameters removed for brevity]
info: http://pubads.g.doubleclick.net/gampad/ads?[parameters removed for brevity]


Hope this helps...
(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.
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 :-\
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. :) )
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.
Okay, I changed the test addon a little: https://builder.addons.mozilla.org/addon/1003406/latest/

It now runs on "*.facebook.com" 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.
http://www.youtube.com/watch?v=c8pkDpN7r-g
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
Marking WFM per comment 19.  Please re-open if you can still reproduce on 1.0b5 or later.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.