Internationalization Failure in Firefox 119

[titusfortner]

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: ""

[whimboo]

@titusfortner just to be sure is it Firefox or Chrome? While the summary says Chrome it's Firefox 119 mentioned in the first comment.

[titusfortner]

No, I'm just bad at attention to detail, the test was running firefox-beta

[titusfortner]

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

[whimboo]

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.

[titusfortner]

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?

[whimboo]

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.

[titusfortner]

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?"

[whimboo]

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.

[titusfortner]

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

[whimboo]

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]

Yes, it did fail when 119 was in beta

[whimboo]

@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.

[whimboo]

Oh wait in https://github.com/titusfortner/geckobug_2139 you did that already.

[whimboo]

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.

[whimboo]

Actually I can replicate in a Marionette test. I'll investigate and file a bug when necessary.

[whimboo]

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.