servoshell: Port Authentication dialog code to use egui instead of tinyfiledialogs

[chickenleaf]

• Part of migration from tinyfiledialogs to egui
• Issues:

1. Enter key when dialog is open, interacts with the webview that is behind the dialog (and not in focus) and ends up queuing another dialog behind.
2. Authentication dialog does not show up without this work around:

pub(crate) fn new_toplevel_webview(self: &Rc<Self>, url: Url) {
        let webview = self.servo().new_webview(url);
        webview.set_delegate(self.clone());
        if self.inner_mut().focused_webview_id.is_none() {
            self.inner_mut().focused_webview_id = Some(webview.id());
        }
        self.add(webview);
    }

3. Cannot access another tab when a dialog is open

---

• ./mach build -d does not report any errors
• ./mach test-tidy does not report any errors
• These changes fix #___ (GitHub issue number if applicable)

• There are tests for these changes OR
• These changes do not require tests because ___

[chickenleaf]

@mrobinson @mukilan

[mrobinson]

Looks good with the changes that @mukilan suggested. This will need a small change in order to remove the workaround.

[mrobinson]

I looked into this a bit and I think it will be hard to fix this issue before we do more changes in the compositor (having a compositor per WebView and setting up the association synchronously when creating WebViews). In the meantime maybe we can look into just setting focused_webview_id as the first WebView we create when creating AppState.

[mrobinson]

I've slightly modified this workaround to be a bit less invasive.

[chickenleaf]

I just pushed this dialog with corrections without the changes you have done, is that alright?
i added the patch @mukilan gave to fix the background mouse interactions and also the Escape and Enter keyboard interactions.

[mrobinson]

@chickenleaf I had pushed my changes to your branch and it seems that your latest push has overriden them and also added a new commit fixing the mouse interaction issue. I think we should go ahead and stick with 284a7ed for this change and then do the mouse interaction fixes in a new PR. I will repush to this branch and then at that point you just need to open a new PR with your changes.

[mrobinson]

Okay. I have pushed the changes again. Nothing more is needed in this PR from you @chickenleaf. Thanks!

[mrobinson]

We need to make sure that when in headless mode we do not create the dialog. I'll make this change.

[mrobinson]

The reason here is that if we are in headless mode, the dialog will be added to the list of dialogs, but never resolved, since there is no UI for the user to resolve it. This headless mode is used for WPT test which is why landing this hit test failures.