Re: [webkit-dev] Test flakiness.
Thanks for the tips Alexey. I suspected order was to blame and wrote a script to run all the LayoutTests/platform/mac/accessibility tests as tuples with the flaky test coming second. The winning combination that reproduces the flaky failure for me: Tools/Scripts/run-webkit-tests --debug LayoutTests/platform/mac/accessibility/document-links.html LayoutTests/platform/mac/accessibility/search-predicate-element-count.html Odd/interesting that order matters. Still chasing down the details, thanks again. On Dec 3, 2013, at 3:23 PM, Alexey Proskuryakov wrote: > > 03 дек. 2013 г., в 14:11, Tim Horton написал(а): > >> It would be ideal if you could figure out *why* the test is flaky. What >> state are the tests that run before it setting that isn’t getting reset? Can >> you narrow it down to a pair of tests? > > One way to do this is to run accessibility tests with "--child-processes=1 > --verbose" options, and to start bisecting if that makes the issue reliable. > > Another useful approach is to make the tests run multiple times with > "--child-processes=1 --verbose —repeat-each=10". > > - WBR, Alexey Proskuryakov > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Test flakiness.
Hey everyone, I've noticed the following build message: Unexpected flakiness: text-only failures (1) platform/mac/accessibility/search-predicate-element-count.html [ Failure Pass ] Oddly, when this test is run ALONE (locally of course), it always passes. Yet, sometimes when run with other tests (say all accessibility tests), it fails. This suggests to me that this test should be considered 'flaky' as order matters (which is odd). What are the criteria for marking a test flaky? Thanks. - Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Watchlist cc rules.
Hey everyone, I’d like to add myself to the “Accessibility” cc rule in the WebKit/Tools/Scripts/webkitpy/common/config/watchlist script. Should I simply file a bug and attach a patch as usual, or does touching this area involve a different procedure (since it’s not really a bug)? Thanks for your help. - Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Commit queue down due to Apple internal network issues
https://bugs.webkit.org/show_bug.cgi?id=122534 Not sure why this one failed to commit. Rebased just incase, but nothing indicates that this is an issue with the patch (at least to me). Possibly related? Thanks for taking a look. - Sam On Oct 14, 2013, at 10:45 AM, Ryosuke Niwa wrote: > This problem appears to have been worked out over the weekend. The commit > queue should be working as expected by now. > > - R. Niwa > > > On Fri, Oct 11, 2013 at 9:53 PM, Ryosuke Niwa wrote: > Hi, > > It appears that the machines running commit queue cannot reach svn.webkit.org > due to some network issues. Please land patches manually until a further > notice. > > If you're not a committer yet, please reply to this thread with a bug number > and I'll land it manually for you (as long as it has been reviewed). > > - R. Niwa > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Accessibility Object Searching
On Jun 22, 2011, at 3:21 PM, Dominic Mazzoni wrote: > On Wed, Jun 22, 2011 at 3:14 PM, Samuel White wrote: >> Thanks for the feedback. I've been prototyping this idea here and it does >> included text searching as you mentioned. My philosophy was to put the >> search functionality right into the AccessibilityObject class and leave the >> job of exposing external APIs up to the experts of each platform save for >> Mac. In the Mac accessibility code I have this functionality exposed under >> accessibilityAttributeValue:forParameter: method where the attribute one >> must pass is AXSearchPredicate. > > I'd love to see the actual proposed spec for AXSearchPredicate. Right > now your proposed change is all in terms of AccessibilityObject, but > that's very WebKit-specific. If you're proposing a new capability to > be added to NSAccessibility, I think it's important to talk about what > the spec means at that level, so that we're sure it could be > implemented by another, non-WebKit browser. The AXSearchPredicate attribute is a working concept at the moment. The parameter is an NSDictionary that contains the following: An AccessibilityObject to start searching from. An NSString that specifies the type of search (ex: @"AXLinkSearchKey"). An NSString that specifies the search direction (ex: @"AXDirectionNext"). An NSString that holds the text to search for. > It might be nice to propose it to, say, IAccessible2 - I know they're > already in the middle of considering proposals for the next version, > so this might be a great place to get feedback. > > https://wiki.mozilla.org/Accessibility/IA2_1.3 > > I'd be happy to try to provide an intro if you'd be willing to > entertain discussion at least. The NSAccessibility API additions are designed to meet the needs of Mac accessibility clients. We're providing in webkit a generic method so that any platform API can take advantage of it. I'll CC you on the patch so you can look at the generic mechanism in order to make sure it meets the needs of another platform's API. >> As for implementation details, I'd like to outline how a search is performed >> in my prototype for you. As I stated above, searching happens in the >> AccessibilityObject class. The function doing the heavy lifting takes an >> AccessibiltySearchPredicate which is just a simple data structure that holds >> the following: >> >> An AccessibilityObject to search within. >> An AccessibilityObject to start searching from (ex: search for X within >> object A but after object B). >> A direction to search in. >> A search type (link search, heading search, bold text search, etc). > > Could you clarify this one? Are you going to enumerate possible > searches? What about just searching for a particular role, would that > work? The Search type exists because I don't think there is a clear relation to just axRoles. For example, if you are searching for the next element containing bold text you would need font information (italic text, underlined text, and italic text come to mind as well). Since a key is used we don't need to enumerate but can instead jump to the correct case for a given search. >> Search text to look for. >> Number of AccessibilityObjects to return. > > These sound fine. > > - Dominic ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Accessibility Object Searching
Hey Dominic, Thanks for the feedback. I've been prototyping this idea here and it does included text searching as you mentioned. My philosophy was to put the search functionality right into the AccessibilityObject class and leave the job of exposing external APIs up to the experts of each platform save for Mac. In the Mac accessibility code I have this functionality exposed under accessibilityAttributeValue:forParameter: where the attribute one must pass is AXSearchPredicate. As for implementation details, I'd like to outline how a search is performed in my prototype for you. As I stated above, searching happens in the AccessibilityObject class. The function doing the heavy lifting takes an AccessibiltySearchPredicate which is just a simple data structure that holds the following: An AccessibilityObject to search within. An AccessibilityObject to start searching from (ex: search for X within object A but after object B). A direction to search in. A search type (link search, heading search, bold text search, etc). Search text to look for. Number of AccessibilityObjects to return. This gives the flexibility to search for just text, or just elements, or both specific text but only within the scope of a specific search type. Thanks again for the initial feedback. Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Accessibility Object Searching
Hey everybody, I'm new to the list and thought it would be a good idea to get some feedback on an accessibility feature before filing a bug or submitting anything. Currently, no functionality exists in WebKit to search through AccessibilityObjects using basic search criteria like next link or next table internally. Screen readers and other access devices often must instead probe WebKit and build up their own internal representation of a page before they can begin searching for what they are after. This presents two big problems for the users of access technology. First, pages such as the HTML 5 working doc have a massive number of DOM elements and building up an external representation can be a very expensive and slow task. Secondly, maintaining an accurate external representation of a site can become difficult if that site has a large amount of dynamic content and users may not be accessing relevant information. I would like to make a few small changes to the AccessibilityObject class that adds the functionality I've mentioned. I think these small but important additions will allow existing access technologies to rely much more on WebKits representation of a page and thus eliminate the problems I've described above. I appreciate any feedback and look forward to helping out. Thanks Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
