Closed Bug 1385418 Opened 7 years ago Closed 7 years ago

Remove disabled pocket code for the toolbar button now that it's been replaced by the item in the page action panel

Categories

(Firefox :: Pocket, defect, P1)

55 Branch
defect

Tracking

()

VERIFIED FIXED
Firefox 57
Iteration:
57.2 - Aug 29
Tracking Status
firefox57 --- verified

People

(Reporter: Gijs, Assigned: adw)

References

Details

(Whiteboard: [photon-structure][high-priority])

Attachments

(1 file)

Splitting this off from bug 1367927 will hopefully help with iterating and landing things as soon as they're ready.
Whiteboard: [photon-structure][triage]
Assignee: nobody → adw
Status: NEW → ASSIGNED
Assignee: adw → nobody
Status: ASSIGNED → NEW
Flags: qe-verify+
Priority: -- → P3
QA Contact: gwimberly
Whiteboard: [photon-structure][triage] → [reserve-photon-structure]
Whiteboard: [reserve-photon-structure] → [reserve-photon-structure][high-priority]
Sorry, this bug should have had a summary update, so I belatedly did that now.

bug 1367927 ended up only creating the pocket button behind a pref. That pref is off by default, so users will currently not have a toolbar button anymore already. This bug exists to remove the code and fix up automated tests to deal with the removal, as the pref is flipped on automation. As such, I don't think it needs to be high-priority. Dolske, does that sound right to you? :-)
Flags: needinfo?(dolske)
Priority: P3 → P4
Summary: Remove pocket from the navbar toolbar once it's in the page action panel + location bar → Remove disabled pocket code for the toolbar button now that it's been replaced by the item in the page action panel
Whiteboard: [reserve-photon-structure][high-priority] → [reserve-photon-structure]
Pocket integration on about:newtab for Activity Stream is broken; see bug 1388528.  We'll use this bug to fix that too.  The Pocket panel/doorhanger should open on the site identity icon in that case.

(In reply to Drew Willcoxon :adw from bug 1388528 comment #8)
> * The Save to Pocket context menu item is broken too:
> https://dxr.mozilla.org/mozilla-central/rev/
> a921bfb8a2cf3db4d9edebe9b35799a3f9d035da/browser/extensions/pocket/bootstrap.
> js#238-254
> 
> * The save/anchor logic is here:
> http://searchfox.org/mozilla-central/source/browser/extensions/pocket/
> content/Pocket.jsm#98
Assignee: nobody → adw
Status: NEW → ASSIGNED
... so this should probably be "high-priority" after all FWIW.
Iteration: --- → 57.1 - Aug 15
Priority: P4 → P1
Whiteboard: [reserve-photon-structure] → [photon-structure]
Whiteboard: [photon-structure] → [photon-structure][high-priority]
Flags: needinfo?(dolske)
Blocks: 1390048
Work in progress.  This will probably end up fixing a couple of other bugs, including bug 1390048.
Iteration: 57.1 - Aug 15 → 57.2 - Aug 29
Blocks: 1387697
No longer blocks: 1390048
No longer depends on: 1367927
Blocks: 1390048
I think this is everything...  It fixes UITour's handling of Pocket too.
Comment on attachment 8897277 [details]
Bug 1385418 - Remove disabled pocket code for the toolbar button now that it's been replaced by the item in the page action panel.

https://reviewboard.mozilla.org/r/168582/#review174386

This looks good to me besides the removal of the CustomizableUI listener, and would have been r+ but for the fact that the page action test is orange on try. It looks like it has something to do with the action command refactor that's part of this patch.

::: browser/base/content/theme-vars.inc.css:160
(Diff revision 2)
>  :root[lwthemeicons~="--forget-icon"] #panic-button:-moz-lwtheme,
> -:root[lwthemeicons~="--pocket-icon"] #pocket-button:-moz-lwtheme {
> -  -moz-image-region: rect(0, 16px, 16px, 0) !important;
> -}

Uh, you meant to keep the contents of the rule, and remove only the pocket selector, I'm sure. :-)

(This is causing the browser/base/content/test/static/browser_parsable_css.js orange on try, which is how I noticed - I missed it first time!)

::: browser/extensions/pocket/bootstrap.js
(Diff revision 2)
>      Services.ppmm.loadProcessScript(PROCESS_SCRIPT, true);
>      PocketReader.startup();
> -    if (PocketPageAction.shouldUse) {
> -      PocketPageAction.init();
> +    PocketPageAction.init();
> -    } else {
> -      CustomizableUI.addListener(this);

The listener is in use for onWindowOpened/onWindowClosed listeners still, I think, to add/remove the rest of the UI? We should probably keep that for now.

::: browser/extensions/pocket/bootstrap.js
(Diff revision 2)
>      AboutPocket.aboutSignup.unregister();
>  
> -    if (PocketPageAction.shouldUse) {
> -      PocketPageAction.shutdown();
> +    PocketPageAction.shutdown();
> -    } else {
> -      CustomizableUI.removeListener(this);

Which also means we should keep the removeListener here.
Attachment #8897277 - Flags: review?(gijskruitbosch+bugs)
(In reply to :Gijs from comment #11)
> and would have been r+ but for the fact that the page action test is orange
> on try. It looks like it has something to do with the action command
> refactor that's part of this patch.

It's because I renamed tempPanel to activatedActionPanel I think.

> ::: browser/base/content/theme-vars.inc.css:160
> (Diff revision 2)
> >  :root[lwthemeicons~="--forget-icon"] #panic-button:-moz-lwtheme,
> > -:root[lwthemeicons~="--pocket-icon"] #pocket-button:-moz-lwtheme {
> > -  -moz-image-region: rect(0, 16px, 16px, 0) !important;
> > -}
> 
> Uh, you meant to keep the contents of the rule, and remove only the pocket
> selector, I'm sure. :-)

Yikes, thanks.

browser_startup_images.js was also failing because the Pocket svg was loaded but not shown, so I fixed that too.  It's the same problem that the bookmark star svg had when I made that a page action.

> ::: browser/extensions/pocket/bootstrap.js
> (Diff revision 2)
> >      Services.ppmm.loadProcessScript(PROCESS_SCRIPT, true);
> >      PocketReader.startup();
> > -    if (PocketPageAction.shouldUse) {
> > -      PocketPageAction.init();
> > +    PocketPageAction.init();
> > -    } else {
> > -      CustomizableUI.addListener(this);
> 
> The listener is in use for onWindowOpened/onWindowClosed listeners still, I
> think, to add/remove the rest of the UI? We should probably keep that for
> now.

PocketOverlay.onWindowOpened is now called by the page action's onPlacedInPanel, so that part of the CUI listener is covered.

There's no PocketOverlay.onWindowClosed, but there is a PocketOverlay.onWidgetAfterDOMChange, which your comment made me take look at.  All it does is show/hide non-primary Pocket UI depending on whether Pocket is "enabled" according to isPocketEnabled.  In addition to checking the pref, isPocketEnabled returns false if Pocket doesn't have a CUI placement.  In the new page action world, pref aside, Pocket is always "enabled/placed," right?  So it's not necessary anymore to show/hide non-primary Pocket UI except on window open.  And that's covered by PocketOverlay.onWindowOpened.

So I removed the onWidgetAfterDOMChange callback and the updateWindowAfterWidgetPlaced method that it delegated to.  The only thing in updateWindowAfterWidgetPlaced that still needs to happen is showing/hiding the reader-view button.
Comment on attachment 8897277 [details]
Bug 1385418 - Remove disabled pocket code for the toolbar button now that it's been replaced by the item in the page action panel.

https://reviewboard.mozilla.org/r/168582/#review174614

Nice! Sorry for missing the onWindowOpened thing. And yes, removing the other callbacks was the right thing.
Attachment #8897277 - Flags: review?(gijskruitbosch+bugs) → review+
Try looks good so far, landing.
Pushed by dwillcoxon@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/397fe94c67f1
Remove disabled pocket code for the toolbar button now that it's been replaced by the item in the page action panel. r=Gijs
https://hg.mozilla.org/mozilla-central/rev/397fe94c67f1
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 57
This seems back-end, but asking as my name is attached to this bug: Any steps needed from me to verify?
Flags: needinfo?(gijskruitbosch+bugs)
(In reply to Grover Wimberly IV [:Grover-QA] from comment #20)
> This seems back-end, but asking as my name is attached to this bug: Any
> steps needed from me to verify?

Probably good to check that pocket items work correctly, both in the page action menu, the library, the bookmarks menu and the page context menu, both with pocket in the URL bar and when it's been removed (you can use the context menu on the item in the url bar for that).
Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(gwimberly)
Hi :adw, I am seeing a talos performance regression in canvasmark, that *looks* like it might be coming from this patch, however I am not certain. Do you think your patch could have caused the perf regression below? Seems odd though when your patch is removing disabled code - that's why I am hesitant to file a perf regression bug against this patch. Please verify, thanks!

== Change summary for alert #8841 (as of August 16 2017 19:12 UTC) ==

Regressions:

  3%  tcanvasmark summary windows7-32 pgo e10s     9,754.57 -> 9,466.46

For up to date results, see: https://treeherder.mozilla.org/perf.html#/alerts?id=8841

https://wiki.mozilla.org/Buildbot/Talos/Tests#CanvasMark
Flags: needinfo?(adw)
It seems impossible for this bug to have regressed *canvas* performance.  This is purely a front-end bug and there's no way it could have impacted any part of the core web platform, like canvas.
Flags: needinfo?(adw)
Blocks: 1394533
I have tested this based on the suggestion in comment 21 and it is verified as fixed.
Status: RESOLVED → VERIFIED
Flags: qe-verify+
Flags: needinfo?(gwimberly)
Depends on: 1390864
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: