Open https://developer.mozilla.org/en-US/docs/Web/HTML/Element/details and observe that Ladybird logs this:

186987.818 WebContent(10539): (js error) DOMException{ "name": "SyntaxError", "message": "Invalid URL for targetOrigin: '[object Object]'", "code": 12, "INDEX_SIZE_ERR": 1, "DOMSTRING_SIZE_ERR": 2, "HIERARCHY_REQUEST_ERR": 3, "WRONG_DOCUMENT_ERR": 4, "INVALID_CHARACTER_ERR": 5, "NO_DATA_ALLOWED_ERR": 6, "NO_MODIFICATION_ALLOWED_ERR": 7, "NOT_FOUND_ERR": 8, "NOT_SUPPORTED_ERR": 9, "INUSE_ATTRIBUTE_ERR": 10, "INVALID_STATE_ERR": 11, "SYNTAX_ERR": 12, "INVALID_MODIFICATION_ERR": 13, "NAMESPACE_ERR": 14, "INVALID_ACCESS_ERR": 15, "VALIDATION_ERR": 16, "TYPE_MISMATCH_ERR": 17, "SECURITY_ERR": 18, "NETWORK_ERR": 19, "ABORT_ERR": 20, "URL_MISMATCH_ERR": 21, "QUOTA_EXCEEDED_ERR": 22, "TIMEOUT_ERR": 23, "INVALID_NODE_TYPE_ERR": 24, "DATA_CLONE_ERR": 25 }

Some details from discussion in Discord:

I had a look at this last week, this is due to step 10 of overload resolution not handling dictionary types, causing the string overload to be called when an object is passed. (See: https://github.com/LadybirdBrowser/ladybird/blob/master/Userland/Libraries/LibWeb/WebIDL/OverloadResolution.cpp#L275)

As mentioned in the first FIXME in the function this should probably be evaluated at code-generation time. I did take a shot at modifying the parsed IDL::Types after all needed information was parsed, but as they're mostly marked as const this took much time just to check if I was right (and is most likely not the right way to do it)