Closed Bug 599771 Opened 9 years ago Closed 9 years ago
Update buttons in the Add-ons Manager to use a consistent id/anonid naming scheme
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.
Attachment #478680 - Flags: review?(dtownsend)
Comment on attachment 478680 [details] [diff] [review] Patch v1 There are some more missing anonids around.
Summary: Restart button links are missing id or anonid → Restart and more button-link's are missing id or anonid
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.
Attachment #478682 - Flags: review?(dtownsend)
Comment on attachment 478682 [details] [diff] [review] Patch v1.1 The details class is used in the theme, please leave it there
Attachment #478682 - Flags: review?(dtownsend) → review-
(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?
Ok, talked with Blair and we should keep it if other themes want to handle the button-link differently. Here an updated patch.
Comment on attachment 479345 [details] [diff] [review] Patch v2 Approved to land post b7
Whiteboard: [has patch][checkin-needed-post-b7]
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.
Whiteboard: [has patch][checkin-needed-post-b7] → [has patch]
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.
Attachment #481167 - Flags: review?(dtownsend)
Summary: Restart and more button-link's are missing id or anonid → Update buttons in the Add-ons Manager to use a consistent id/anonid naming scheme
Whiteboard: [has patch] → [has patch][mozmill-needed]
Sorry, I don't understand why mozmill requires such consistency, can you explain?
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 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.
Attachment #481167 - Flags: review?(dtownsend) → review-
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!
Now the patch of the correct size. The browser_details patch was not complete.
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.
Updated patch which fix all the remaining failures of the browser chrome tests.
Comment on attachment 479345 [details] [diff] [review] Patch v2 Marking as obsolete in favor of the larger patch.
Attachment #479345 - Attachment is obsolete: true
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Whiteboard: [has patch][mozmill-needed] → [mozmill-needed]
Target Milestone: --- → mozilla2.0b8
No regressions happened with this change. Marking as verified fixed.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.