WIP: Edge Browser Scheduled Job timeout

[amartya4256]

No description provided.

[fedejeanne]

I would additionally reduce the timeout introduced in #1677 to 10 seconds (+5 seconds from your new timeout) just to make sure that your change here actually covers all failing tests and use cases. If it does then I would expect to see no timeouts hitting 10s, only timeouts after 5s.

WDYT?

[github-actions]

Test Results

   493 files  +  1     493 suites  +1   13m 36s ⏱️ + 6m 43s
 4 293 tests +190   4 083 ✅  -  13   8 💤 +1  0 ❌ ±0  202 🔥 +202 
16 531 runs  +380  16 232 ✅ +173  97 💤 +5  0 ❌ ±0  202 🔥 +202 

For more details on these errors, see this check.

Results for commit ae4fcac. ± Comparison against base commit 413426e.

♻️ This comment has been updated with latest results.

[amartya4256]

I would additionally reduce the timeout introduced in #1677 to 10 seconds (+5 seconds from your new timeout) just to make sure that your change here actually covers all failing tests and use cases. If it does then I would expect to see no timeouts hitting 10s, only timeouts after 5s.

WDYT?

Alright, I'll add it here.

[HeikoKlare]

I think we need to have another thorough look at what may cause Edge initialization to block the UI thread. When trying to test the timeout logic, I came across several places where I can introduce blocking operations that will not be caught by this proposal.

When systematically going through the public methods of Edge, I see that the calls to getWebView*() and isWebView*Availabile() are the ones that block in case initialization or any of the subsequently scheduled futures do not finish timely.
Then, taking a look at which calls may potentially block inside those methods, I see these two:

• waitForFutureToFinish()
• future.join()

The latter will be captured for the initialization future by the timeout added in this PR. The former will only partly be resolved, as inside waitForFutureToFinish() there is a call to processNextOSMessage(), which spins a loop that may be blocking as well. Thus, I think we need to break that potentially blocking operation as well. Maybe we can simply spin Display.readAndDisplay() in the loop checking for future completion (inside waitForFutureToFinish()) instead of having the additional loop inside processNextOSMessage()?

Then, what about the other callers of processNextOSMessage()? In particular, createEnvironment() is called synchronously when creating the first Edge instance. May that one block as well? I also see further calls of that method of which I am not sure if they are correct. We need to check them as well.

[HeikoKlare]

In case we run into a timeout, the initialization needs to be properly rolled back in terms of the state of Edge being cleaned up and potentially OS resources to be freed, like in the abortion logic of createControllerInitializationCallback().

[HeikoKlare]

Instead of only throwing an error, should we maybe hide the (uninitialized) browser widget and add a label informing the user about the failed initialization instead? Calling something like this inside the execution on display might do the trick:

	private void replaceWithErrorLabel() {
		browser.setVisible(false);
		Label errorLabel = new Label(browser.getParent(), SWT.WRAP);
		errorLabel.setForeground(browser.getDisplay().getSystemColor(SWT.COLOR_RED));
		errorLabel.setText("Edge browser initialization failed");
		errorLabel.setLocation(0, 0);
		errorLabel.setSize(browser.getSize());
	}