Closed Bug 1257831 Opened 10 years ago Closed 10 years ago

L10N Snapshot Tests fail on loading web pages

Categories

(Firefox for iOS :: Build & Test, defect)

Other
iOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: st3fan, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

This happens for both tr and bn-IN: ✗ test10ReloadButtonContextMenu, Asynchronous wait failed: Exceeded timeout of 60 seconds, with unfulfilled expectations: "Expect predicate `value BEGINSWITH "100"` for object ProgressIndicator". ** TEST FAILED ** Is it possible that the page loads so fast that we never see that the progress bar hits 100%? I think what I want to do is add some known elements to those test pages so that we can simply wait until the actual content is ready. That should be more robust.
That control might also be localized, and show either non-latin numbers, or leads with % instead of the number or something like that. At least in turkish, a quick glance says that it's %50.
This patch moves away from using the progress bar to find out of a page has loaded and instead waits for a specific element to appear. The element has to have an `aria-label` attached. For example, this is what one of our test pages now looks like: ``` <html> <head> <meta name="viewport" content="width=device-width"> </head> <body aria-label="body"> <a href="http://www.mozilla.org" aria-label="link"><img src="image.png"></a> </body> </html> ``` We load it with: ``` loadWebPage("http://people.mozilla.org/~sarentz/fxios/testpages/link.html", waitForOtherElementWithAriaLabel: "body") ``` And you can reference the link with: ``` app.webViews.elementBoundByIndex(0).links["link"].pressForDuration(2.0) ``` (Future work, move the test pages into our repo too)
Attachment #8732243 - Flags: review?(etoop) → review+
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: