The embedder should be handling prompts and alerts

[paulrouget]

As of now, alerts are handled by browserhtml via a mozbrowser event, or we use tinyfiledialogs in the script thread. mozbrowser is going away.

We should not use tinyfiledialogs in libservo, but in /ports/.

[fabricedesre]

How do you see that work? Using an additional method in the embedder and let the embedder send back a message to unblock the script thread execution?

[paulrouget]

Yes. See how allow_navigation works for example.

[jdm]

Relevant code:

• servo/components/constellation/constellation.rs

  Lines 1845 to 1851 in 34f3882

  	// Allow the embedder to handle the url itself
  	let (chan, port) = ipc::channel().expect("Failed to create IPC channel!");
  	let msg = EmbedderMsg::AllowNavigation(top_level_browsing_context_id, load_data.url.clone(), chan);
  	self.embedder_proxy.send(msg);
  	if let Ok(false) = port.recv() {
  	return None;
  	}

  (example of communicating with the embedder that can be used as a model)

• servo/components/script/dom/window.rs

  Lines 544 to 550 in 34f3882

  	let (sender, receiver) = ProfiledIpc::channel(self.global().time_profiler_chan().clone()).unwrap();
  	self.send_to_constellation(ScriptMsg::Alert(s.to_string(), sender));
  	let should_display_alert_dialog = receiver.recv().unwrap();
  	if should_display_alert_dialog {
  	display_alert_dialog(&s);
  	}

  (this already communicates with the constellation to decide whether to show a prompt, then shows the prompt)

• servo/components/script/dom/permissions.rs

  Lines 311 to 329 in 34f3882

  	#[cfg(target_os = "linux")]
  	fn prompt_user(message: &str) -> PermissionState {
  	if opts::get().headless {
  	return PermissionState::Denied;
  	}
  	match tinyfiledialogs::message_box_yes_no(DIALOG_TITLE,
  	message,
  	MessageBoxIcon::Question,
  	YesNo::No) {
  	YesNo::Yes => PermissionState::Granted,
  	YesNo::No => PermissionState::Denied,
  	}
  	}
  	#[cfg(not(target_os = "linux"))]
  	fn prompt_user(_message: &str) -> PermissionState {
  	// TODO popup only supported on linux
  	PermissionState::Denied
  	}

  (this needs to communicate with the embedder via the constellation)

I'll file separate issues for the uses in components/bluetooth and components/net, since they need to be solved differently. I'm providing this information so some specific contributors can work on this issue; please check with me first before starting to work on it if I have not discussed it with you.

[jdm]

Filed #20428 and #20429 for the net and bluetooth bits.

[gterzian]

In the light of #20329, where Script would need to ask the embedder to allow unloading of a document:

1. I starting looking into it and realized script doesn't have a channel to the embedder yet, and also that script doesn't seem to be aware of it's own top level browsing context.
2. I assume constellation shouldn't block waiting for the response from the embedder.
3. In the light of the above, it seems we will have to send a first message from script to constellation, containing a response sender, and then constellation could send a message to the embedder containing the top level browsing context id, and the response sender. The embedder could then directly respond to script via this response sender.

Does this architecture makes sense? Should we instead add a EmbedderProxy directly on script_thread and ask for the top level browsing context id from constellation?

I saw that currently the Alert message also isn't yet forwarded to the embedder, see

servo/components/constellation/constellation.rs

Line 1757 in 954ac81

// FIXME: forward alert event to embedder

So I propose a separate PR to deal with all of this. Sounds good?

[paulrouget]

A very similar problem is being addressed here: #20480 and see #20480 (comment)

[paulrouget]

I had a quick chat with @cbrewster and we agree that it's fine if the script thread has access to the EmbedderProxy. We could short-circuit the constellation.