599771 - Update buttons in the Add-ons Manager to use a consistent id/anonid naming scheme

Status: VERIFIED FIXED

(Toolkit :: Add-ons Manager, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Attachment: Patch v1

The restart button link doesn't have any anonid accociated to it. That makes it hard to easily find this button. An anonid should be added, similar to all the other buttons.

We need this fix to let Mozmill handle this button link.

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Comment on attachment 478680 [details] [diff] [review]
Patch v1

There are some more missing anonids around.

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Attachment: Patch v1.1

I hope it's ok to move out the details class into the anonid. I wasn't able to find any other code and test which relies on it. It will make it consistent to all other button links.

Comment 3

[Dave Townsend [:mossop]]

Comment on attachment 478682 [details] [diff] [review]
Patch v1.1

The details class is used in the theme, please leave it there

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to comment #3)
> Comment on attachment 478682 [details] [diff] [review]
> Patch v1.1
> 
> The details class is used in the theme, please leave it there

Is there any reason why we need the details class? All other button-link elements don't rely on this class and I'm sure we don't want to have a different styling for the restart link case. A quick search on MXR showed me that it's only this single element which makes use of the detail class:

http://mxr.mozilla.org/mozilla-central/search?string=class=%22detail&find=xml

It's only this extensions.xml file.

Class details:
http://mxr.mozilla.org/mozilla-central/source/toolkit/themes/gnomestripe/mozapps/extensions/extensions.css#345

What's the reason for having this extra class?

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Attachment: Patch v2

Ok, talked with Blair and we should keep it if other themes want to handle the button-link differently. Here an updated patch.

Comment 6

[Dave Townsend [:mossop]]

Comment on attachment 479345 [details] [diff] [review]
Patch v2

Approved to land post b7

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+1]]

As what we have seen by further working with Mozmill on the AOM, there are a couple more instances with an inconsistent usage of the btn suffix. It makes it really hard for us to get those elements. It would be really helpful when all the button would have that prefix, especially the ones with the same name in the different views (restart, undo, ...). 

As talked with Blair on IRC I have written a patch which I have now send to the tryserver. Once I get results which are hopefully green, I will upload a new patch tomorrow.

Comment 8

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Attachment: Patch v3

As said in the comment before, the current naming scheme for buttons makes it hard for us to offer helper functions in the AddonsAPI for Mozmill tests, which makes it easier to create tests.

With this patch all buttons get an "-btn" prefix, as long as they don't appear twice in different views. For those cases the class name should be sufficient. I have submitted the patch to the tryserver and all tests passed. I hope that we can get this patch integrated. If that's the case v2 of the patch is obsolete.

Comment 9

[Dave Townsend [:mossop]]

Sorry, I don't understand why mozmill requires such consistency, can you explain?

Comment 10

[Henrik Skupin [:whimboo][⌚️UTC+1]]

It will make it much easier for us to retrieve elements of the same type by using a helper function like getAddonButton() or others, instead of having to customize it for each single element because of its different naming.

If you do not want to have the latest patch attached in the code, we should at least get the first patch in. Having an id/anonid at all is much more important.

Comment 11

[Dave Townsend [:mossop]]

Comment on attachment 481167 [details] [diff] [review]
Patch v3

We can probably take this so long as we do so a.s.a.p. but this patch does not apply to current trunk so it needs to be updated.

Comment 12

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Attachment: PAtch v4

The reason why it failed to apply was the addition of synthesizeMouseAtCenter for EventUtils. I have updated the patch and Blair mentioned via IRC that he will be so kind to run the tests locally to make sure that I haven't missed anything. Thanks!

Comment 13

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Attachment: PAtch v4.1

Now the patch of the correct size. The browser_details patch was not complete.

Comment 14

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Comment on attachment 482426 [details] [diff] [review]
PAtch v4.1

Tests fail. I will run all the tests tomorrow before attaching a new version of the patch.

Comment 15

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Attachment: Patch v4.2

Updated patch which fix all the remaining failures of the browser chrome tests.

Comment 16

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Comment on attachment 479345 [details] [diff] [review]
Patch v2

Marking as obsolete in favor of the larger patch.

Comment 17

[Dave Townsend [:mossop]]

Landed: http://hg.mozilla.org/mozilla-central/rev/0b6940d11a43

Comment 18

[Henrik Skupin [:whimboo][⌚️UTC+1]]

No regressions happened with this change. Marking as verified fixed.