396059 - Create new Talos suite: run basic startup tests from non-ASCII paths

Status: RESOLVED WONTFIX

(Testing :: Talos, defect)

Description

[(not currently active) Ted Mielczarek]

Given bugs like bug 396052, we should at least be trying to launch the browser from a non-ASCII path.  We could possibly do this on the perftest machines.  It'd be nice to avoid future bustage like this.

Comment 1

[(not currently active) Ted Mielczarek]

Also it looks like we're broken on Win32 with a non-ascii username, so that'd be good to test too.

Comment 2

[(not currently active) Ted Mielczarek]

See also bug 396199.

Comment 3

[alice nodelman [:alice] [:anode]]

Moving to Talos component.

Comment 4

[alice nodelman [:alice] [:anode]]

Is this worth having a whole test devoted to it?  Sounds more like a unit test then a talos test, is all.

Comment 5

[(not currently active) Ted Mielczarek]

My original summary was simply "should run basic startup tests from non-ASCII paths". It's kind of a PITA to write tests that have to start the browser specially right now, since we don't have a harness for that, but I don't really care if this were to be Talos or just some other new harness.

Comment 6

[Burak Yiğit Kaya [:BYK]]

This is actually not very complicated. If you add "!!python/str" tag in front of the browser_path definition in the yml file and ensure that the yml file is encoded in utf-8, it works correctly.

One other way is to loop over all the parsed yaml values and decode them to utf-8 encoded strings instead of unicode strings.

Changing setEnvironmentVars to use str decoding is not a good option since the parameters passed can be instances of int or some other class.

Comment 7

[Burak Yiğit Kaya [:BYK]]

Adding jhammel since this may be related with his efforts on PerfConfigurator.

Comment 8

[Joel Maher ( :jmaher ) (UTC -8)]

this isn't needed for a performance test, lets resolve as a unittest.