geckodriver
geckodriver copied to clipboard
mozilla
Internationalization Failure in Firefox 119
System
- Version: latest
- Platform: n/a
- Firefox: 119
- Selenium: trunk
This was working in 118 and broke when we updated to 119
Testcase
https://github.com/SeleniumHQ/selenium/blob/selenium-4.13.0/java/test/org/openqa/selenium/I18nTest.java#L78
Stacktrace
https://gypsum.cluster.engflow.com/invocation/e988f896-09b9-43ba-9bf5-112418633bb0
expected: "𠀀𠜎𠀋𪆐𪚲"
but was: ""
@titusfortner just to be sure is it Firefox or Chrome? While the summary says Chrome it's Firefox 119 mentioned in the first comment.
No, I'm just bad at attention to detail, the test was running firefox-beta
I'm not at all familiar with the atom tests, but it looks like they are all failing for character related things in Firefox Beta & Dev as well: https://github.com/SeleniumHQ/selenium/actions/runs/6533321213/job/17738888379
Is that reproducible when running locally? Maybe you could tell me which command I have to run to get this affected test executed? I always have problems with Java tests, especially when it comes to using a custom browser binary.
This is a tough one. I can 100% reproduce it in Java in nightly Nightly does not enter the text, and v117 does, but there's no difference in the logs: https://gist.github.com/titusfortner/4b2dac4b6d12fd1c1f6ba7dec3a3c84d (unless that addons.xpi is something?)
I was getting the failure in Ruby, but then it started working and I can't get it to fail again. Might be how the unicode is formatted since Java sends it as a byte stream instead of plain text?
Ok, so which command do I have to use to run this particular test with the Java bindings by using a custom Firefox binary? If I could get this information then I can check that myself, and try to find the regressor.
Also did you also try with a 118 Nightly or now release build yet? Does that also happen with a Firefox 119 beta or the upcoming release today? Or is it bound to Nightly? It could mean that there is a feature only turned on for Nightly.
This is reproducible: https://github.com/titusfortner/geckobug_2139
Right now 119 is passing and 120 is failing. Not sure why. Is there something different in "production?"
Interesting. Is 120 on your side a current beta release or Nightly? It might be that there is a specific feature enabled for Nightly but not for beta/release builds.
Yes, only stable version passes:
String PASSING_VERSION = "119";
String FAILING_VERSION = "120";
String NIGHTLY_VERSION = "nightly"; // 121
String BETA_VERSION = "beta"; // 120
String DEV_VERSION = "dev"; // 120
String STABLE_VERSION = "stable"; // 119
Interesting. We do not have logic that only makes release different. So maybe a feature that rides the train and is now on beta. I might be good to know if 119 also failed when it was on beta.
I'll try to find some time to test myself in the next days.
@titusfortner with Firefox 120 released does it work with that release as well? Is it really only beta that is affected?
Also do you have a chance to create a dedicated repository that I could clone and get the tests to run with a simple command? I don't have any Java environment installed locally and I don't know how to run the above testcase. A Python testcase would be nice as well.
Oh wait in https://github.com/titusfortner/geckobug_2139 you did that already.
Ok, I can see it passing with the 120 release and failing with 121 beta. Is there a way to use a Nightly build or a custom build of Firefox? @titusfortner, what would I have to change to make that happen?
As what I can see so far is that Element Send Keys fails to actually input the characters into the input field.
Actually I can replicate in a Marionette test. I'll investigate and file a bug when necessary.
Ok, so thanks again for the testcase @titusfortner! I've fully investigated and the problem is on our side and indeed only visible in Nightly and early beta (developer builds) releases.
Our work is tracked on https://bugzilla.mozilla.org/show_bug.cgi?id=1866431.