676300 - Cannot use history.pushState / history.replaceState in page-mod

Status: RESOLVED FIXED

(Add-on SDK Graveyard :: General, defect, P2)

Description

[Naohiro Koriyama]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0a1) Gecko/20110803 Firefox/8.0a1
Build ID: 20110803030753

Steps to reproduce:

In my addon using page-mod, I use history.pushState / history.replaceState.


Actual results:

Exception occurs.

An exception occurred.
Traceback (most recent call last):
<snip>
  File "resource://jid1-41t58upr92mimq-at-jetpack-api-utils-lib/content/content-proxy.js", line 92, in null
    let unwrapResult = Function.prototype.apply.apply(fun, [obj, args]);
[Exception... "Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED) [nsIDOMHistory.replaceState]"  nsresult: "0x8000ffff (NS_ERROR_UNEXPECTED)"  location: "JS frame :: resource://jid1-41t58upr92mimq-at-jetpack-api-utils-lib/securable-module.js -> resource://jid1-41t58upr92mimq-at-jetpack-api-utils-lib/content/content-proxy.js :: <TOP_LEVEL> :: line 92"  data: no]



Expected results:

should work correctly with no exception.

Comment 1

[Naohiro Koriyama]

When I use same script on Greasemonkey, it works as I excepted.

Comment 2

[Alexandre Poirot [:ochameau]]

Thanks for the report.

I wasn't able to found the precise reason of this exception.
It is something new introduced in future version of Firefox.
(It works correctly in Firefox5)

By default I would say that it is related to additional security checks described in bug 676572.
But I launch a new Firefox debug build on current Nightly in order to find the exact reason of this error.

In the meantime, you can use: unsafeWindow.history.pushState.
This `unsafeWindow` is experimental and not documented. It allows to bypass default security wrappers.

Comment 3

[Alexandre Poirot [:ochameau]]

I found the precise problem with gdb.
We end up here:
  http://mxr.mozilla.org/mozilla-central/source/js/src/jsclone.cpp#533
`obj` refer to the proxy created by us before passing values to XrayWrappers.
And obj->isObject() returns false on a Proxy because its class is `js_ProxyClass`:
  http://mxr.mozilla.org/mozilla-central/source/js/src/jsobj.h#1349

I don't think we can build a generic fix as these "xraywrappers proxies" are important and we can't distinguish between native methods that have to receive json only values from methods that may receive JS objects with methods.

Nevertheless, we can easily fix this by adding another work around in content-proxy module.

Comment 4

[Alexandre Poirot [:ochameau]]

Attachment: Fix history API by adding a specific work around

Add this specific work around.

Comment 5

[Naohiro Koriyama]

(In reply to Alexandre Poirot (:alex) from comment #4)
> Created attachment 552495 [details] [diff] [review]
> Fix history API by adding a specific work around
> 
> Add this specific work around.

Applying this fix, my add-on works properly.

Comment 6

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

Comment on attachment 552495 [details] [diff] [review]
Fix history API by adding a specific work around

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

r+, but this code get's less and less maintainable. Do we have a list of platform bugs that we will eventually allow us to get rid of our proxy wrapper hacks ? If not we should create them and point out in comments what is workaround for what.

Comment 7

[Alexandre Poirot [:ochameau]]

I opened bug 679054 for the platform issue. I'm not 100% convinced this is a platform issue. We have to address it but I don't think that these APIs have to accept Proxy objects.

Comment 8

[Alexandre Poirot [:ochameau]]

Landed:
https://github.com/mozilla/addon-sdk/commit/95f6db0f00a41c2b780e63ec2c05fabe4c6e1d5d

I've added a reference to the platform bug number in comments.
Most work arounds have a reference to a bug number, when I was able to identify a real issue from platform code.