Bugzilla

So I've got my test running locally. I've tried a bunch of things, and I cannot seem to get it to fail locally. I've been running it like so `./mach test browser_discovery_render.js --repeat=100` Even tried it on 300 a few times.

It def feels like a race condition, but I don't understand it much. Nothing about the changes in the pr would cause a race condition. My only theory is the race condition was always there, but because the string was hard coded, it was always fast enough to win the race. Now that the string is fluent, it's a bit slower? thus now sometimes doesn't win.

If that's the case, I think Gavin's patch is going help by making the test wait for a different condition.

Is there a way though to wait until fluent is done?

Another idea is we no longer have our test look at a string that's fluent based as the finish condition, maybe just the existence of a css clas? It's not testing fluent so I don't see the need to use fluent as the condition.

So I've got my test running locally. I've tried a bunch of things, and I cannot seem to get it to fail locally either. I've been running it like so `./mach test browser_discovery_render.js --repeat=100` Even tried it on 300 a few times.

It def feels like a race condition, but I don't understand it much. Nothing about the changes in the pr would cause a race condition. My only theory is the race condition was always there, but because the string was hard coded, it was always fast enough to win the race. Now that the string is fluent, it's a bit slower? thus now sometimes doesn't win.

If that's the case, I think Gavin's patch is going help by making the test wait for a different condition.

Is there a way though to wait until fluent is done?

Another idea is we no longer have our test look at a string that's fluent based as the finish condition, maybe just the existence of a css clas? It's not testing fluent so I don't see the need to use fluent as the condition.