Closed Bug 1156065 Opened 9 years ago Closed 9 years ago

"Sending message that cannot be cloned"-warning in SiteSpecificUserAgent.js

Categories

(Firefox :: General, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
Firefox 41
Tracking Status
e10s + ---
firefox41 --- fixed

People

(Reporter: elbart, Assigned: ttaubert)

References

Details

Attachments

(3 files, 1 obsolete file)

When visiting a site like mozilla.org, this message pops up in the Console:

Sending message that cannot be cloned. Are you trying to send an XPCOM object? SiteSpecificUserAgent.js:50:0

https://hg.mozilla.org/mozilla-central/annotate/a32e3b93c8d8/dom/base/SiteSpecificUserAgent.js#l50

(Message coming from bug 1139718)
> When visiting a site like mozilla.org, this message pops up in the Console:

Which console?  Browser console?  Web console?  Something else?

I can't reproduce this in a clean profile with a current-ish nightly (and in particular, the code from bug 1139718 is not getting hit at all).  Are you seeing this in a clean profile?
Flags: needinfo?(elbart)
Attached image sitespecificuseragent.png (obsolete) —
(In reply to Not doing reviews right now from comment #1)
> Which console?  Browser console?  Web console?  Something else?

Browser console.

> I can't reproduce this in a clean profile with a current-ish nightly (and in
> particular, the code from bug 1139718 is not getting hit at all).  Are you
> seeing this in a clean profile?

Yes.

Screenshot made with 2015-04-20 with no pre-existing profile, so it's the very first start where it's loading the firstrun-page.
Flags: needinfo?(elbart)
(Please delete the previous attachment #8595288 [details] if possible, thanks.)
Comment on attachment 8595288 [details]
sitespecificuseragent.png

I can't delete this, but I can hide it from non-security-group members...

Thank you for following up!
Comment 5 is private: false
Attached image browser_console.png
I am also seeing this.  These messages appear hundreds of times during browsing sessions.  There seem to be 3 different files triggering this:

parent.js:279:0
SiteSpecificUserAgent.js:50:0
<unknown>
Ah, now I managed to reproduce this.  This is happening in e10s only, in the child process only, and only on hostnames that have not been visited so far, basically.

So the SiteSpecificUserAgent bit is due to this code in getUserAgentForURIAndWindow:

  let data = { uri: aURI };
  let result = cpmm.sendRpcMessage("Useragent:GetOverride", data)[0]

where aURI is an nsIURI.  So yeah, that will fail to clone correctly....

Bill, what should this code be doing instead?
Status: UNCONFIRMED → NEW
Component: DOM → General
Ever confirmed: true
Flags: needinfo?(wmccloskey)
Product: Core → Firefox
It looks like the only property we use on the URI is asciiHost. So we could just send that:
  let data = { uri: { asciiHost: aURI.asciiHost } };

We don't have a generic way to send URIs over IPC. We usually just send the spec and make a new one on the other side.
Flags: needinfo?(wmccloskey)
Flags: needinfo?(gavin.sharp)
Not clear what the needinfo is for. Sounds like a bug for the e10s backlog.
tracking-e10s: --- → ?
Flags: needinfo?(gavin.sharp)
Needinfo was for who gets to own this.
Depends on: 1139718
See Also: → 1160818
Looks like we have no tests for this... I'd prefer to file a follow-up and leave this to :mchang.
Assignee: nobody → ttaubert
Status: NEW → ASSIGNED
Attachment #8610228 - Flags: review?(wmccloskey)
Huh? I haven't dealt with any of this code before, what did you need?
Flags: needinfo?(ttaubert)
Hmmm. I thought blame said you wrote this... Let me check again.
Flags: needinfo?(ttaubert)
Looks like you did in bug 927633?
(In reply to Tim Taubert [:ttaubert] from comment #14)
> Looks like you did in bug 927633?

Ahh I see, thanks for finding that. Been a long time since I've seen this code.
Comment on attachment 8610228 [details] [diff] [review]
0001-Bug-1156065-Send-cloneable-messages-from-SiteSpecifi.patch

Review of attachment 8610228 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks for doing this.
Attachment #8610228 - Flags: review?(wmccloskey) → review+
https://hg.mozilla.org/integration/fx-team/rev/e15b0c115585

Had to backout because of failures like this:

http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/fx-team-linux/1432808854/fx-team_ubuntu32_vm_test-mochitest-5-bm06-tests1-linux32-build95.txt.gz

TEST-UNEXPECTED-FAIL | netwerk/test/mochitests/test_user_agent_overrides.html | Navigator UA not overridden at step 1 - got Mozilla/5.0 (X11; Linux i686; rv:41.0) Gecko/20100101 Firefox/41.0, expected DummyUserAgent
TEST-UNEXPECTED-FAIL | netwerk/test/mochitests/test_user_agent_overrides.html | Navigator UA not overridden at step 5 - got Mozilla/5.0 (X11; Linux i686; rv:41.0) Gecko/20100101 Firefox/41.0, expected DummyUserAgent/5.0 (X11; Linux i686; rv:41.0) Gecko/20100101 Firefox/41.0
TEST-UNEXPECTED-FAIL | netwerk/test/mochitests/test_user_agent_updates.html | Test timed out. - expected PASS

There is a ton of these in the log too:

JavaScript error: resource://gre/modules/UserAgentOverrides.jsm, line 92: TypeError: searchHost.indexOf is not a function

Someone should take a look at this as well... Not sure I can find time to do that in the near future, sorry.
Assignee: ttaubert → nobody
Status: ASSIGNED → NEW
Turns out the API is used directly when loaded in the parent (boo) and also by Fennec. I think we should leave the API intact and just re-create the URI on the other side.
Assignee: nobody → ttaubert
Attachment #8610228 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #8613212 - Flags: review?(wmccloskey)
Attachment #8613212 - Flags: review?(wmccloskey) → review+
https://hg.mozilla.org/mozilla-central/rev/0b26d1be9caa
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 41
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: