Closed Bug 874371 Opened 11 years ago Closed 11 years ago

(Australis) failing panorama tests checking for toolbar item presence on UX builds

Categories

(Firefox Graveyard :: Panorama, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: Gijs, Assigned: Gijs)

References

Details

Attachments

(1 file, 1 obsolete file)

Failures look like this:

21:41:56  WARNING -  TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/components/tabview/test/browser_tabview_bug626791.js | name-group: panorama button should be in the toolbar - Didn't expect -1, but got it
21:41:57  WARNING -  TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/components/tabview/test/browser_tabview_bug626791.js | drag-to-create-group: panorama button should be in the toolbar - Didn't expect -1, but got it
21:41:59  WARNING -  TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/components/tabview/test/browser_tabview_bug626791.js | create-orphan: panorama button should be in the toolbar - Didn't expect -1, but got it
21:42:00  WARNING -  TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/components/tabview/test/browser_tabview_bug626791.js | drag-to-create-orphan: panorama button should be in the toolbar - Didn't expect -1, but got it
21:42:01  WARNING -  TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/components/tabview/test/browser_tabview_bug626791.js | re-adding-after-removal: panorama button should be in the toolbar - Didn't expect -1, but got it

The problem is that browser-tabview.js ( http://mxr.mozilla.org/mozilla-central/source/browser/base/content/browser-tabview.js#412 ) modifies currentset rather than using insertItem to insert its toolbar button.

I see two options:
1. Implement a setter for toolbar currentsets.
2. Change the panorama code to use insertItem instead.

I personally favour option 2, but I don't know if we're going to have to do 1 anyway for add-on compat, and some part of me feels a little uneasy changing other code to deal with our things. On top of that, without Australis, using insertItem is per-window, which is presumably what the currentset code was trying to avoid...
Attached patch Patch (obsolete) — Splinter Review
This switches to insertItem (and CustomizableUI for removing, because actually calling .remove() makes insertItem balk when we try to reinsert it).

Mike, do you think we can take this road, or should we cave and implement currentset setting? Is that even an option without accidentally overriding the pref when restoring a document with persisted setting stuff?
Assignee: nobody → gijskruitbosch+bugs
Status: NEW → ASSIGNED
Attachment #752164 - Flags: feedback?(mconley)
Oops, forgot to check the alltabs button hasn't been taken out / moved...
Attachment #752164 - Attachment is obsolete: true
Attachment #752164 - Flags: feedback?(mconley)
Attachment #752168 - Flags: feedback?(mconley)
Comment on attachment 752168 [details] [diff] [review]
Patch with insertItem/CustomizableUI

Review of attachment 752168 [details] [diff] [review]:
-----------------------------------------------------------------

I think this is the preferred route. I think we want to get away from currentset and replace it with something better, and not re-implement it.

::: browser/base/content/browser-tabview.js
@@ +425,5 @@
>        return;
>  
> +    let allTabsBtn = document.getElementById("alltabs-button");
> +    let nextItem = allTabsBtn.nextSibling;
> +    toolbar.insertItem("tabview-button", nextItem);

We should use buttonId instead of "tabview-button".

::: browser/components/tabview/test/browser_tabview_bug626791.js
@@ +30,5 @@
>      let buttonId = "tabview-button";
>      let pos = currentSet.indexOf(buttonId);
>  
>      if (-1 < pos) {
> +      Cu.import("resource:///modules/CustomizableUI.jsm");

We're probably OK importing this at the top of the file.
Attachment #752168 - Flags: feedback?(mconley) → feedback+
Comment on attachment 752168 [details] [diff] [review]
Patch with insertItem/CustomizableUI

Review of attachment 752168 [details] [diff] [review]:
-----------------------------------------------------------------

What Mike said :) Thanks!
Attachment #752168 - Flags: review+
Thanks Mike & Tim!

http://hg.mozilla.org/projects/ux/rev/1f1144b5a14f
Whiteboard: [fixed-in-ux]
These have gone green, hurray!
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
... except then it wasn't. Totally jinxed it. Will try to see what's wrong with the last failing test (seems to be somewhat intermittent?).
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
The last failure looks like it was fixed by bug 874584...
Status: REOPENED → RESOLVED
Closed: 11 years ago11 years ago
Resolution: --- → FIXED
https://hg.mozilla.org/mozilla-central/rev/1f1144b5a14f
Whiteboard: [fixed-in-ux]
Depends on: 972822
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: