Closed Bug 883555 Opened 11 years ago Closed 6 years ago

How should Marionette .text/get_text handle directional strings?

Categories

(Remote Protocol :: Marionette, defect)

Other
All
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: zcampbell, Unassigned)

References

Details

(Keywords: pi-marionette-spec, Whiteboard: [affects=b2g])

Probably more one for the W3C team...

B2G is starting to make use of Bi-directional strings (http://www.unicode.org/reports/tr9/ ), in one case I found using \u202a and \u202c.

For the `.text` attribute Marionette returns the string with these unicode tags in it. As they are "invisible" Python cannot easily use the string returned by Marionette for string matching.

Should they be stripped out or interpreted by WebDriver or Marionette before they reach the test framework? 

As my interpretation of the spec is that WebDriver will only return visible text to the user so I feel like Marionette should be doing something to them.
Summary: Should Marionette .text/get_text interpret directional strings → How should Marionette .text/get_text handle directional strings?
Zac

I seem to have lost where this is being used, can you tell me which test to run to reproduce?
Flags: needinfo?(zcampbell)
I tried to reproduce with http://jsbin.com/yahuyaci/2 and couldn't
This is tested on v1.5 tip but this code has not changed for a long time so you could do this on v1.3 or v1.4 too on engineering builds.

Testamacase:

# Setup
# 1. Open Settings app
# 2. Tap Language 
# 3. Tap "English (US)" select menu to open system select menu
# Now start Marionette as below

>>> from marionette import Marionette
>>> m = Marionette()
>>> m.start_session()
-- snip --
>>> print [e.text for e in m.find_elements('css selector', '#value-selector-container li')]
[u'\u202b\u0639\u0631\u0628\u064a\u202c', u'\u202aCatal\xe0\u202c', u'\u202a\u010ce\u0161tina\u202c', u'\u202aDeutsch\u202c', u'\u202a\u0395\u03bb\u03bb\u03b7\u03bd\u03b9\u03ba\u03ac\u202c', u'\u202aEnglish (US)\u202c', u'\u202aEspa\xf1ol\u202c', u'\u202aFran\xe7ais\u202c', u'\u202aHrvatski\u202c', u'\u202aMagyar\u202c', u'\u202aNederlands\u202c', u'\u202aPolski\u202c', u'\u202aPortugu\xeas (do Brasil)\u202c', u'\u202aRom\xe2n\u0103\u202c', u'\u202a\u0420\u0443\u0441\u0441\u043a\u0438\u0439\u202c', u'\u202aSloven\u010dina\u202c', u'\u202a\u0421\u0440\u043f\u0441\u043a\u0438\u202c', u'\u202aSrpski\u202c', u'\u202aT\xfcrk\xe7e\u202c', u'\u202a\u6b63\u9ad4\u4e2d\u6587 (\u7e41\u9ad4)\u202c']
Flags: needinfo?(zcampbell)
raised https://www.w3.org/Bugs/Public/show_bug.cgi?id=25306 and will fix in the Selenium project
Blocks: 937050
This affects=b2g because we have hacks to workaround it that we'd like to remove.
Whiteboard: [affects=b2g]
One of the things the WebDriver WG wants to do is compare the innerText specification (http://rocallahan.github.io/innerText-spec/index.html) with the current atoms.  Presumably innerText handles whitespace correctly for bidi input.
I think the answer here is that we want to do whatever the getElementText atom does.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INVALID
Product: Testing → Remote Protocol
You need to log in before you can comment on or make changes to this bug.