Closed Bug 1059855 Opened 10 years ago Closed 7 years ago

[e10s] Buffer extension's toolbar button disappears after restarting Firefox when e10s are enabled

Categories

(Firefox :: Extension Compatibility, defect, P3)

Product:
Firefox
Component:
Extension Compatibility
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
e10s + ---

People

(Reporter: geeknik, Unassigned)

References

(
URL
)

Details

(Whiteboard: Selection API, triaged) 

When I set browser.tabs.remote.autostart to true, the Buffer extension does not load (no icon) and refuses to load even if I disable/re-enable or uninstall/re-install.
FYI, I've sent an email to the support staff @ Buffer pointing them to the e10s wiki and this bug.
(In reply to Brian Carpenter [:geeknik] from comment #1)
> FYI, I've sent an email to the support staff @ Buffer pointing them to the
> e10s wiki and this bug.

Brian, thanks so much for digging into this here. I'm Dan and I work on the extensions at Buffer. I'm trying to catch up on e10s, what it is and what it means for the Buffer extension. I'm not quite sure I understand what is causing the issue here, but I really want to figure it out before e10s hits Firefox stable. Do you have any insight into what's happening here?
Daniel, you can install Firefox Nightly here: http://nightly.mozilla.org/. e10s is on by default on that branch. The add-on docs are here: https://developer.mozilla.org/en-US/Add-ons/Working_with_multiprocess_Firefox. You can also go to the #e10s IRC channel if you want to discuss this live with a member of the e10s team.
It looks like Buffer v2.7.4 for Firefox now works with e10s in Firefox Nightly. If for some reason the icon doesn't initially show up, disabling it and re-enabling in the Add-ons Manager causes the Buffer icon to show back up. 

I've tested posting to Buffer via the icon and it seems to be working. I can either close this now as resolved or I can keep it open as e10s is still evolving and the extension might stop working again in the future.
(In reply to Brian Carpenter [:geeknik] from comment #4)
> It looks like Buffer v2.7.4 for Firefox now works with e10s in Firefox
> Nightly. If for some reason the icon doesn't initially show up, disabling it
> and re-enabling in the Add-ons Manager causes the Buffer icon to show back
> up. 
> 
> I've tested posting to Buffer via the icon and it seems to be working. I can
> either close this now as resolved or I can keep it open as e10s is still
> evolving and the extension might stop working again in the future.

Wow, thanks for the update Brian! I think it might be good to keep this open for now since e10s is still evolving.

Dan, Buffer
Dan, FYI restarting the browser causes the Buffer icon to disappear, it doesn't stay in place like the other icons (Adblock Plus, HTTPS Everywhere, etc). I have to disable and re-enable the extension after every restart in order to use it.
Summary: [e10s] Buffer extension does not load at all when e10s are enabled → [e10s] Buffer extension's toolbar button disappears after restarting Firefox when e10s are enabled
Dan, has there been any progress in resolving the toolbar button bug?
Flags: needinfo?(daniel.j.farrelly)
Jorge, from an end user perspective, the answer is no. The latest version of Buffer still fails to load properly with e10s enabled.
(In reply to Jorge Villalobos [:jorgev] from comment #7)
> Dan, has there been any progress in resolving the toolbar button bug?

(In reply to Brian Carpenter [:geeknik] from comment #8)
> Jorge, from an end user perspective, the answer is no. The latest version of
> Buffer still fails to load properly with e10s enabled.

Unfortunately, I haven't gotten to look into this further. We've gotten reports of this same issue when users upgrade their browser to Firefox 36.x and I cannot get to the bottom of it. I really have no idea why this is happening. I don't see any breaking changes with how we've written the extension. I would absolutely love if either of you guys had any further insight here or might know a good direction to send me to investigate this further! I've added a link to the source code in github:

https://github.com/bufferapp/buffer-firefox

Thanks for your help Brian & Jorge :)
Flags: needinfo?(daniel.j.farrelly)
Trying to deprecate some usage of low-level APIs to see if that helps. I'm getting some CPOW warnings which I'm trying to figure out, but still working through it!

Current progress: https://github.com/bufferapp/buffer-firefox/pull/8
Looks like my dev build of the Buffer addon is working again with Nightly with e10s! When I removed some unused require's here it fixed it up:

https://github.com/bufferapp/buffer-firefox/commit/2e5fc48e55fa54fc4bf65e8bc7ddd882e8f89352

Specifically, I could reproduce this by adding/remove the `var selection = require('sdk/selctedion');` line. Not really sure why this did it, but wanted to add this so it may help someone else :) I'm hoping to do a bit more testing in stable then push a new release tomorrow (should be 2.8.6).

Big thanks to "jimm" and "ted" in IRC for helping me test with the NightlyDebug build.
Sorry to keep posting here with updates, but I've posted a beta here if anyone wants to try it out (I'll take this down when I release it tomorrow/later this week :)

https://www.dropbox.com/s/uuvk8ivl22raufm/buffer-2.8.6-beta1.xpi?dl=0
Well, the button stays in place now, but when I click on it, nothing happens. The Browser Console just shows this after I click the button:

Unable to run script because scripts are blocked internally.

My other extensions are working just fine.
I noticed something interesting. If I load up about:performance in a new tab and I click on the Buffer (v2.11.2) icon, it pops up a window like it should. Obviously the URL is invalid, but it's a start. Still unable to get the Buffer extension to work with normal URLs.
The extension (v2.12.2) icon has started it's disappearing act again with Nightly (v42.0a1).
I can confirm this also happens with Nightly x64 Build 42.0a1 (2015-07-17) with E10's and Buffer 2.12.3
Also I've got the error below in Browser Console.

http://pastebin.com/2ccRACNF
In the latest build of Firefox 42.0a1, I see this in the Browser Console when I click on the Buffer icon:

unsafe CPOW usage worker.js:127:0
unsafe CPOW usage utils.js:259:0
unsafe CPOW usage utils.js:78:0
unsafe CPOW usage worker.js:150:0
unsafe CPOW usage bufferSrc.js:45:0
unsafe CPOW usage bufferSrc.js:47:0
unsafe CPOW usage bufferSrc.js:54:0
unsafe CPOW usage bufferSrc.js:55:0
unsafe CPOW usage bufferSrc.js:176:0
unsafe CPOW usage bufferSrc.js:177:0
unsafe CPOW usage bufferSrc.js:63:0
unsafe CPOW usage bufferSrc.js:81:0
unsafe CPOW usage bufferSrc.js:84:0
unsafe CPOW usage bufferSrc.js:32:0
TypeError: object in compartment marked as invisible to Debugger webconsole.js:434:21
unsafe CPOW usage Console.jsm:100:0
unsafe CPOW usage Console.jsm:101:0
unsafe CPOW usage Console.jsm:207:0
unsafe CPOW usage Console.jsm:208:0
unsafe CPOW usage Console.jsm:209:0
unsafe CPOW usage Console.jsm:210:0
Unable to run script because scripts are blocked internally. <unknown>
Is this bug still occurring? Is there any upcoming fix for this?
Flags: needinfo?(daniel.j.farrelly)
Flags: needinfo?(brian.carpenter)
(In reply to Jerod Lycett from comment #19)
> Is this bug still occurring? Is there any upcoming fix for this?

It still happens with 42.0a1 (2015-07-24) (64bit) and Buffer 2.12.6.
Yes it is still an issue. Buffer refuses to comment on if they will be fixing it. They just keep apologizing for my troubles.

(In reply to Jerod Lycett from comment #19)
> Is this bug still occurring? Is there any upcoming fix for this?
Flags: needinfo?(daniel.j.farrelly)
Flags: needinfo?(brian.carpenter)
I don't know why it removed the other needinfo flag when I commented.
Flags: needinfo?(daniel.j.farrelly)
Hey y'all—

I took a look at this independently; you can see my notes on the problem in Buffer's Github issues: https://github.com/bufferapp/buffer-firefox/issues/13

In short, my experience was that something breaks with the require of the Selection API. I have not yet looked into this as much as I'd like, but I do wonder whether the break on the inclusion indicates a problem with the API itself and e10s as I don't see any documentation that says that including the API in main.js would cause trouble.

Thoughts?
Hey all,

(In reply to Brian Carpenter [:geeknik] from comment #21)
> Yes it is still an issue. Buffer refuses to comment on if they will be
> fixing it. They just keep apologizing for my troubles.
> 
> (In reply to Jerod Lycett from comment #19)
> > Is this bug still occurring? Is there any upcoming fix for this?

100% we will be fixing this. To be totally transparent, after I was able to make it stable and working in my own testing on Nightly in late March, I haven't tested much on e10s Firefox. In the extension area we've been quite busy working on some issues and development for Firefox stable and other browsers as they have greater usage than FF Nightly. Our plan right now is to get this fixed 100% prior to full e10s launch which from my knowledge is still due around Nov 2015?

We're not ignoring this issue and we really do appreciate all of the help and investigation happening on this thread and Github.


(In reply to Kai Curtis from comment #23)
> In short, my experience was that something breaks with the require of the
> Selection API. I have not yet looked into this as much as I'd like, but I do
> wonder whether the break on the inclusion indicates a problem with the API
> itself and e10s as I don't see any documentation that says that including
> the API in main.js would cause trouble.

Thanks so much for your investigation Kai! This does indeed go hand in hand with when I removed the selection API earlier this year (https://github.com/bufferapp/buffer-firefox/commit/2e5fc48e55fa54fc4bf65e8bc7ddd882e8f89352). We added it back in for the Pablo feature like you mentioned, but we need to look into why the selection API is causing issues with e10s. It does seem strange that simply including the selection API causes it to crash.

We haven't forgotten about this one!
Flags: needinfo?(daniel.j.farrelly)
The Buffer extension is now completely unusable with Firefox Nightly: "Buffer could not be verified for use in Nightly and has been disabled." now shows up in the Add-ons Manager. There is no way to re-enable the extension without diving into the about:config.
(In reply to daniel.j.farrelly from comment #24)
> Hey all,
> 
> (In reply to Brian Carpenter [:geeknik] from comment #21)
> > Yes it is still an issue. Buffer refuses to comment on if they will be
> > fixing it. They just keep apologizing for my troubles.
> > 
> > (In reply to Jerod Lycett from comment #19)
> > > Is this bug still occurring? Is there any upcoming fix for this?
> 
> 100% we will be fixing this. To be totally transparent, after I was able to
> make it stable and working in my own testing on Nightly in late March, I
> haven't tested much on e10s Firefox. In the extension area we've been quite
> busy working on some issues and development for Firefox stable and other
> browsers as they have greater usage than FF Nightly. Our plan right now is
> to get this fixed 100% prior to full e10s launch which from my knowledge is
> still due around Nov 2015?
> We haven't forgotten about this one!

According to https://wiki.mozilla.org/Electrolysis#Schedule it'll be default in beta in late September, as you can see, they're still holding off on putting it into release at all. Let me ping someone who may be able to get you more help.
Flags: needinfo?(cpeterson)
(In reply to Jerod Lycett from comment #26)
> (In reply to daniel.j.farrelly from comment #24)
> > 100% we will be fixing this. To be totally transparent, after I was able to
> > make it stable and working in my own testing on Nightly in late March, I
> > haven't tested much on e10s Firefox. In the extension area we've been quite
> > busy working on some issues and development for Firefox stable and other
> > browsers as they have greater usage than FF Nightly. Our plan right now is
> > to get this fixed 100% prior to full e10s launch which from my knowledge is
> > still due around Nov 2015?
> > We haven't forgotten about this one!
> 
> According to https://wiki.mozilla.org/Electrolysis#Schedule it'll be default
> in beta in late September, as you can see, they're still holding off on
> putting it into release at all. Let me ping someone who may be able to get
> you more help.

Thanks, Jerod. AFAIK, the plan is still to allow opt-in e10s in Beta 41 (August 10 aka today!). From our opt-in experience with Nightly and Aurora, I can expect about 50% opt-in. e10s will be opt-out in Beta 42 (September 21).
Flags: needinfo?(cpeterson)
As of the 30 September 2015 build of 44.0a1 (Built from https://hg.mozilla.org/mozilla-central/rev/9169f652fe5e69c2d77ac31929934a5bc3342e6e), the Buffer extension is kind of working. I can get it to pop up the window, I can get logged in via Twitter and I can post to Twitter via Buffer, HOWEVER, sometimes when I click the Buffer icon, every tab crashes. Interesting side effect.
The Buffer extension continues to work with the 02 October 2015 build of 44.0a1 (Built from https://hg.mozilla.org/mozilla-central/rev/5f16c6c2b969f70e8da10ee34853246d593af412). All tabs still crash upon the first (and sometimes second/third) click on the Buffer icon. You also have to go into the extension page and disable/enable the Buffer extension in order for the icon to display.
The Buffer extension has stopped working again with the 23 October 2015 build of 44.0a1 (Built from https://hg.mozilla.org/mozilla-central/rev/0625c68c0abcfe4d10880d15d8fe7d06df3369c9).
(In reply to daniel.j.farrelly from comment #24)
> > (In reply to Jerod Lycett from comment #19)
> > > Is this bug still occurring? Is there any upcoming fix for this?
> 
> 100% we will be fixing this. To be totally transparent, after I was able to
> make it stable and working in my own testing on Nightly in late March, I
> haven't tested much on e10s Firefox. In the extension area we've been quite
> busy working on some issues and development for Firefox stable and other
> browsers as they have greater usage than FF Nightly. Our plan right now is
> to get this fixed 100% prior to full e10s launch which from my knowledge is
> still due around Nov 2015?
Hi, just want to keep you up to date, e10s will be entering A/B testing in Beta on Monday.
It appears that the Buffer app is working almost correctly in Firefox Nightly 47.0a1 (Built from https://hg.mozilla.org/mozilla-central/rev/5f9ba76eb3b1fd9377bbdb4cc2f98a7e75eabdfb). I can install the extension. I can login to the extension with Twitter. I can even post to Twitter using the extension, however, when I restart the browser, the icon for the extension is missing and the only way to get it to re-appear is to disable and re-enable the extension. So we're back to where we started.
Triage team, Looking at comment 24 it sounds like this is the API with issues.  Is this a top level API that had been fixed or replaced with webextensions?

Daniel - if you happen to read this - for timing... e10s has started going out to a portion of GA users in 48 (excluding people with add-ons).  we'll be starting to include add-ons that are marked MPC=true (multi-process compatible) or are webextensions over 50-51 (possibly 52 if metrics say to delay).  users who aren't in that catagory - until 52 - will just not be able to get e10s.
Whiteboard: Selection API
doing a slight update - as if all the Beta work and telemetry comes back.. we will try to go broadly to add-ons by Fx51 (Jan 23rd 2017 in Release).  we keep the updated schedule here and have a blog pending on further out plans). https://docs.google.com/spreadsheets/d/1OFYrrvAFg8y1mZOEbuIR1axxtV8eul_be6ad9fe8JB0/edit#gid=1952061950
Hey everyone! Philippe here, also working on Buffer's Firefox extension – thanks a lot for the regular updates and nudges, and apologies for the lack of updates from our side!

We're keeping an interested eye on how things progress on the e10s front, and are regularly checking out the schedule spreadsheet shared above to make sure we'll be ready when e10s hits Release for add-ons users if not earlier. This doc has been super helpful to keep track of things, thanks for that!

One hope is that WebExtensions – which was already in great shape last time we checked it out – will continue making progress so that we can start seamlessly sharing most of our Chrome/Firefox codebases before e10s is out. Looking forward to the next steps!
With the exception of the add-on not loading when you launch the browser (icon not visible, 'Buffer this page' missing from the right click context menu, etc), the extension does work: I can log in via Twitter,  I can post to Twitter, etc. It's just an annoyance at this point having to go into the add-ons manager every time I launch the browser to click disable/enable in order to load the extension.
(In reply to Philippe Masset from comment #35)
> One hope is that WebExtensions – which was already in great shape last time
> we checked it out – will continue making progress so that we can start
> seamlessly sharing most of our Chrome/Firefox codebases before e10s is out.
> Looking forward to the next steps!

Is there anything that you are blocked on for porting to WebExtensions that we can help out with?
Flags: needinfo?(philippem+bugzilla)
(In reply to Andy McKay [:andym] from comment #37)
> Is there anything that you are blocked on for porting to WebExtensions that
> we can help out with?

Thanks for checking in! Just gave WebExtensions another go, running through the list of APIs we use, and I'm happy to report that all major functionality should now be compatible "with minimum fuss", as is the goal of WebExtensions – awesome!

The last step for a completely working WebExtensions-based Firefox extension will be to clean up how context and background scripts communicate, since currently some wires seem to get crossed.

Other than that, everything looks great, so I'm confident we'll get there soon enough!
Priority: -- → P3
Whiteboard: Selection API → Selection API, triaged
Just an update, I'm seeing the following in WinDbg when I enable Buffer 2.13.37 after restarting Nightly v53.0a1:

Thu Jan 12 20:03:25.596 2017 (GMT-6): console.error: buffer: 
Thu Jan 12 20:03:25.597 2017 (GMT-6):   Message: Error: cross-process JS call failed
  Stack:
    bufferOverlay@resource://gre/modules/commonjs/toolkit/loader.js -> resource://jid1-zuyu7tgkwejaya-at-jetpack/lib/bufferSrc.js:32:5
createOverlay@resource://gre/modules/commonjs/toolkit/loader.js -> resource://jid1-zuyu7tgkwejaya-at-jetpack/lib/bufferSrc.js:229:9
executeAfter@resource://gre/modules/commonjs/toolkit/loader.js -> resource://jid1-zuyu7tgkwejaya-at-jetpack/lib/bufferSrc.js:184:13
getData/</<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://jid1-zuyu7tgkwejaya-at-jetpack/lib/bufferSrc.js:203:21
get@resource://gre/modules/commonjs/toolkit/loader.js -> resource://jid1-zuyu7tgkwejaya-at-jetpack/lib/bufferSrc.js:166:42
getData/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://jid1-zuyu7tgkwejaya-at-jetpack/lib/bufferSrc.js:200:17
getData@resource://gre/modules/commonjs/toolkit/loader.js -> resource://jid1-zuyu7tgkwejaya-at-jetpack/lib/bufferSrc.js:198:14
exports.bufferData@resource://gre/modules/commonjs/toolkit/loader.js -> resource://jid1-zuyu7tgkwejaya-at-jetpack/lib/bufferSrc.js:237:5
attachOverlay@resource://gre/modules/commonjs/toolkit/loader.js -> resource://jid1-zuyu7tgkwejaya-at-jetpack/lib/main.js:104:5
onClick@resource://gre/modules/commonjs/toolkit/loader.js -> resource://jid1-zuyu7tgkwejaya-at-jetpack/lib/main.js:273:9
emitOnObject@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/event/core.js:112:9
emit@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/event/core.js:89:38
@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/ui/button/action.js:101:3
emitOnObject@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/event/core.js:112:9
emit@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/event/core.js:89:38
receive@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/event/utils.js:115:5
next@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/event/utils.js:37:24
filter/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/event/utils.js:54:7
transform/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/event/utils.js:44:29
emitOnObject@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/event/core.js:112:9
emit@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/event/core.js:89:38
receive@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/event/utils.js:115:5
next@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/event/utils.js:37:24
filter/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/event/utils.js:54:7
transform/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/event/utils.js:44:29
emitOnObject@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/event/core.js:112:9
emit@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/event/core.js:89:38
onBuild/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/ui/button/view.js:155:11
EventListener.handleEvent*EventTargetInterposition.methods.addEventListener@resource://gre/modules/RemoteAddonsParent.jsm:641:5
interposeProperty/desc.value@resource://gre/components/multiprocessShims.js:157:52
onBuild@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/ui/button/view.js:153:7
wrapWidgetEventHandler/aWidget[aEventName]@resource://app/modules/CustomizableUI.jsm:2398:16
buildWidget@resource://app/modules/CustomizableUI.jsm:1332:16
getWidgetNode@resource://app/modules/CustomizableUI.jsm:885:16
insertNodeInWindow@resource://app/modules/CustomizableUI.jsm:1138:26
insertNode@resource://app/modules/CustomizableUI.jsm:1124:7
onWidgetAdded@resource://app/modules/CustomizableUI.jsm:930:5
notifyListeners@resource://app/modules/CustomizableUI.jsm:2097:11
createWidget@resource://app/modules/CustomizableUI.jsm:2207:9
createWidget@resource://app/modules/CustomizableUI.jsm:3256:7
create@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/ui/button/view.js:122:3
setup@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/ui/button/action.js:60:5
@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/core/disposable.js:45:56
dispatch@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/method/core.js:119:12
initialize@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/core/disposable.js:135:17
constructor@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/core/heritage.js:146:23
addNavBarButton@resource://gre/modules/commonjs/toolkit/loader.js -> resource://jid1-zuyu7tgkwejaya-at-jetpack/lib/main.js:264:18
@resource://gre/modules/commonjs/toolkit/loader.js -> resource://jid1-zuyu7tgkwejaya-at-jetpack/lib/main.js:287:1
evaluate@resource://gre/modules/commonjs/toolkit/loader.js:444:19
load@resource://gre/modules/commonjs/toolkit/loader.js:497:5
main@resource://gre/modules/commonjs/toolkit/loader.js:929:10
run@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/addon/runner.js:147:19
startup/</<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/addon/runner.js:87:9
process@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:917:23
walkerLoop@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:801:7
Promise*scheduleWalkerLoop@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:734:11
schedulePromise@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:765:7
completePromise@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:702:7
handler@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/addon/window.js:56:3
EventListener.handleEvent*EventTargetInterposition.methods.addEventListener@resource://gre/modules/RemoteAddonsParent.jsm:641:5
interposeProperty/desc.value@resource://gre/components/multiprocessShims.js:157:52
@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/addon/window.js:54:1
evaluate@resource://gre/modules/commonjs/toolkit/loader.js:444:19
load@resource://gre/modules/commonjs/toolkit/loader.js:497:5
_require@resource://gre/modules/commonjs/toolkit/loader.js:803:16
require@resource://gre/modules/commonjs/toolkit/loader.js:757:12
startup/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/addon/runner.js:72:21
process@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:917:23
walkerLoop@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:801:7
Promise*scheduleWalkerLoop@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:734:11
schedulePromise@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:765:7
completePromise@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:702:7
readURI/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/net/url.js:50:9
onStopRequest@resource://gre/modules/NetUtil.jsm:128:17
Thanks Brian! Hopefully that won't be an issue for long, see below :)

Quick update: we've fully ported the Buffer extension to WebExtensions and are currently doing a round of internal QA before actually releasing it – it's happening!

We'll be releasing it before the end of January, but I'd love to give access to anyone who'd like to use it ahead of time! I'll update this thread as soon as the new version is officially out.
Flags: needinfo?(philippem+bugzilla)
Update: The Buffer extension running on WebExtensions has just been released! It's being reviewed on AMO, and our self-hosted version is already up to date: https://buffer.com/extensions

We ran a round of QA and all was well, so full steam ahead with WebExt! Both the Buffer toolbar icon disappearing and the issue with the Selection API mentioned in this thread are no more. Think we can now close this bug – really appreciate the help and suggestions since it was first submitted a while ago, thanks all!
Great news, thanks for the update Philippe.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Couple of nits that probably don't belong here, but I'll address them anyways:

1) Where did the modal go? The extension now opens a new tab when you click the Buffer icon. The old extension only did this on a few site, for the majority a modal was overlaid the site in the current tab.

2) The new tab that opens, doesn't automatically close after you `Add to Buffer`. An annoyance that adds extra clicks to anyone's social media routine. (;
Hey Brian, thanks for sharing these!

About (1), we haven't changed the behavior there, agreed that the modal's much better :) One possible reason for the new tab opening consistently instead of the modal, is if third-party cookies are disabled: could you double-check that after enabling them the modal is indeed back? (It could require disabling/re-enabling the extension)

As for (2), thanks for spotting this – I opened an issue (https://github.com/bufferapp/buffer-firefox/issues/18) to keep track of it, I'm hoping to fix it asap.

Feel free to continue the convo about either of these points in the issue above :)
You need to log in before you can comment on or make changes to this bug.