Provide a Sender for ServiceWorker object to communicate to its ServiceWorkerGlobalScope

[creativcoder]

Note: This is assigned to myself.

In order to implement the postMessage api for the ServiceWorker object, we need to have a Sender to its corresponding ServiceWorkerGlobalScope. From the current implementation of SW api's, we do not have a way to store a Sender<ServiceWorkerScriptMsg>, in ServiceWorker object as the creation of object and its global scope is decoupled with the global scope being created inside the ServiceWorkerManager at a later stage.

The issue has been described here discussing approaches.

Need suggestions from @jdm

[jdm]

It could be an IpcSender to the ServiceWorkerManager which could route the messages, I suppose.

[jdm]

To work around the cyclic issues, one option might be to do something like the OpaqueScriptLayoutChannel we used to have: 49d244d#diff-ac20d4dfaff4522ec78bdd6f12f7445cL233 . There may also be a way to use traits in a similar fashion as the rest of that commit...

[jdm]

Although pub struct OpaqueScriptLayoutChannel(pub (Box<Any + Send>, Box<Any + Send>)); will prevent us from sending it over IPC channels, which may prevent us from using it :<

[jdm]

Another idea: if we have a set of messages that can be sent to the ServiceWorkerGlobalScope from the ServiceWorker by routing them through the Constellation, what if those messages are defined in script_traits instead of trying to reuse ServiceWorkerScriptMsg?

[creativcoder]

Using a seperate message in script_traits would be an option, but then again we will also need to send StructuredCloneData(which resides in script) to ServiceWorkerGlobalScope for postMessage impl. :|

[jdm]

Sending StructuredCloneData wouldn't make much sense; we could send Vec<u8> instead by porting https://dxr.mozilla.org/mozilla-central/rev/6e191a55c3d23e83e6a2e72e4e80c1dc21516493/dom/base/StructuredCloneHolder.cpp#357 .

[creativcoder]

So, do you mean something like below would work ? The vec is Vec<u64>, as StructuredCloneData is a *mut u64

fn PostMessage(&self, cx: *mut JSContext, message: HandleValue) -> ErrorResult {
        let data = try!(StructuredCloneData::write(cx, message));
        let mut msg_vec : Vec<u64> = Vec::new();
        let mut msg_ptr = msg_vec.as_mut_ptr();
        data.move_to_arraybuffer(msg_ptr);
        if let Some(ref sender) = *self.msg_sender.borrow() {
            let _ = sender.send(msg_vec);
        }
        Ok(())
    }

where move_to_arraybuffer is defined on StructuredCloneData as:

/// converts a StructuredCloneData to Vec<u64>
    pub fn move_to_arraybuffer(&self, dst: *mut u64) {
        unsafe {
            ptr::copy_nonoverlapping(self.data, dst, self.nbytes);
        }
    }

Correct me if i misunderstood the way of converting a StructuredClone to a Vec<u8>.

[Ms2ger]

You could extract the bytes with

slice::from_raw_parts(self.data, self.nbytes).to_vec()

but the idea was very much to send StructuredCloneData around; that's what it's for. If we want to use it in script_traits, we could define it there with an api like

pub unsafe fn new(data: *mut u64, nbytes: size_t) -> StructuredCloneData {}
pub unsafe fn extract(self) -> (*mut u64, size_t) {}

[jdm]

Pointers don't serialize over IPC channels, hence the Vec I propose. @creativcoder, that should work, but the Vec needs to reserve the right number of bytes and use u8 to ensure that nbytes is correct.

[creativcoder]

Thanks @Ms2ger and @jdm for the valuable feedback. My mentioned snippet was causing servo to crash (most likely due to copy_nonoverlapping), but using slice::from_raw_parts as @Ms2ger suggested makes it work and postMessage now works on ServiceWorker object. Making a PR soon for this. :)