
|
If you were logged in you would be able to see more operations.
|
|
|
|
Original Estimate:
|
Unknown
|
Remaining Estimate:
|
Unknown
|
Time Spent:
|
Unknown
|
|
|
If you send a very long getEval or runScript command, you'll find that it takes quite a while to run. That's because we transmit Selenium RemoteCommands to the browser as URI-encoded name value pairs, like this:
cmd=click&1=blah+blah+blah%2F%2F
On the browser side, we use "decodeURIComponent" to unpack the values into their appropriate Unicode-encoded strings.
The trouble with this is that "decodeURIComponent" is orders of magnitude slower on IE. On FF, decoding a 300K string takes <16ms, but on IE, it can take 13-14 seconds.
To fix this, we'd have to select some other mechanism of serializing the data to the browser (perhaps JSON). This shouldn't need to impact the clients; we should continue to accept the same URIs we've been using, but decode them in the server and then translate them into something else to translate them to the browser. We'll also have to take care to specify correct character encoding headers in the HTTP response, something we haven't had to worry about much up until this point.
|
|
Description
|
If you send a very long getEval or runScript command, you'll find that it takes quite a while to run. That's because we transmit Selenium RemoteCommands to the browser as URI-encoded name value pairs, like this:
cmd=click&1=blah+blah+blah%2F%2F
On the browser side, we use "decodeURIComponent" to unpack the values into their appropriate Unicode-encoded strings.
The trouble with this is that "decodeURIComponent" is orders of magnitude slower on IE. On FF, decoding a 300K string takes <16ms, but on IE, it can take 13-14 seconds.
To fix this, we'd have to select some other mechanism of serializing the data to the browser (perhaps JSON). This shouldn't need to impact the clients; we should continue to accept the same URIs we've been using, but decode them in the server and then translate them into something else to translate them to the browser. We'll also have to take care to specify correct character encoding headers in the HTTP response, something we haven't had to worry about much up until this point. |
Show » |
|
the same test works fine in revision 2075. What is the timeline for fixing this, or can we roll it back?
-Jen