Created attachment 478680 [details] [diff] [review] 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 on attachment 478680 [details] [diff] [review] Patch v1 There are some more missing anonids around.
Created attachment 478682 [details] [diff] [review] 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 on attachment 478682 [details] [diff] [review] Patch v1.1 The details class is used in the theme, please leave it there
(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?
Created attachment 479345 [details] [diff] [review] 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 on attachment 479345 [details] [diff] [review] Patch v2 Approved to land 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.
Created attachment 481167 [details] [diff] [review] 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.
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.
Created attachment 482425 [details] [diff] [review] 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!
Created attachment 482426 [details] [diff] [review] PAtch v4.1 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.
Created attachment 482512 [details] [diff] [review] Patch v4.2 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.
No regressions happened with this change. Marking as verified fixed.