Some comments inline: From: Martijn <[email protected]> Reply: Martijn <[email protected]> Date: December 11, 2015 at 9:36:51 AM To: Gareth Aye <[email protected]> CC: dev-fxos <[email protected]> Subject: Re: Failed jsmarionette live coding session yesterday
On Wed, Dec 9, 2015 at 3:48 PM, Gareth Aye <[email protected]> wrote: > So if you're writing a simple test and crashing gecko in the near future, > check the gecko logs and also make sure that you have the correct > accessibility stuff! I have some questions: What od you mean with crashing Gecko? If Gecko is really crashing here, then we should file a bug about this, no? Because crashing is really bad. Or do you mean that the test is failing here? Why is accessibility tied into the Marionette code at all? I think there are a couple of things here. Accessibility checks are enabled by default in Gaia only (since it’s our user facing interface) and not marionette in general so it should not affect any other places where marionette is used (unless it’s explicitly enabled). Though I would love to have them enabled across all products that use marionette for testing. Why accessibility and marionette: You can think of accessibility as something that bridges user intention of performing a task and an ability to complete it. It is also our (and I would suggest Mozilla’s) approach that we do not want to have special solutions for accessibility and we want to develop our products that are accessible to all users in the same way. This is why marionette is very useful for testing that user actions, such as clicking and tapping for example, work for all users (including the users of the assistive technologies). Marionette is also better suited for that because testing for accessibility attributes present (unit testing) does not guarantee something being accessible. Also, testing that some component or widget has an accessible interface (from platform accessibility point of view) does not guarantee that it is usable by the user either (in the same sense as it would be for a non-accessibility user). This is why integration testing is crucial because we are most interested in users accomplishing things. I noticed also when I was trying to fix https://bugzilla.mozilla.org/show_bug.cgi?id=1200197 (see comment 22) For me it seems that accessibility has often different needs on which elements are clickable then what we need for regular UI testing. What I also encountered with in Marionette was https://bugzilla.mozilla.org/show_bug.cgi?id=1203966 where we have an unminified atoms.js file, which currently stuck at a version and can't be updated. Regards, Martijn > On Wed, Dec 9, 2015 at 3:39 PM, Gareth Aye <[email protected]> wrote: >> >> I just debugged what was going on and found that >> >> 1449692934326 Marionette DEBUG conn2 <- Response {id: 33, error: >> {"error":"element not accessible","message":"Element is not currently >> visible via the accessibility API and may not be manipulated by it -> id: >> light, tagName: DIV, className: red\n","stacktrace":null}, body: null} >> >> was being thrown by the marionette server and crashing gecko. The reason >> for that was that my traffic light app didn't have the appropriate >> accessibility designations. Calling marionette.client() with the options >> >> { desiredCapabilities: { raisesAccessibilityExceptions: false } } >> >> prevents that from happening. Getting marionette server logs from >> marionette-js-runner was the key to debugging that fwiw. >> >> Cheers, >> Gareth > > > > _______________________________________________ > dev-fxos mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-fxos > _______________________________________________ dev-fxos mailing list [email protected] https://lists.mozilla.org/listinfo/dev-fxos
_______________________________________________ dev-fxos mailing list [email protected] https://lists.mozilla.org/listinfo/dev-fxos
