Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1081)
Subject: Re: Futon test suite on Chrome
From: Jan Lehnardt <jan@apache.org>
In-Reply-To: <AANLkTi=cSPLcN=-URuKJHbnnf7kfvkqgNrY993Xvwg-M@mail.gmail.com>
Date: Wed, 18 Aug 2010 16:45:53 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <E1F30071-0507-49A0-BBB8-A462F36FD35C@apache.org>
References: <AANLkTi=cSPLcN=-URuKJHbnnf7kfvkqgNrY993Xvwg-M@mail.gmail.com>
To: dev@couchdb.apache.org

Hi Robert,

I committed that as part of r986710 as it also fixes=20
support for Safari 5. Thanks for the digging :)

Cheers
Jan
--=20

On 7 Aug 2010, at 14:36, Robert Newson wrote:

> All,
>=20
> I spent a few hours this morning trying to get the full test suite
> running on Chrome. I failed for interesting reasons that I think are
> worth sharing.
>=20
> Exactly two tests fail, attachments.js and replication.js
>=20
> attachments.js fails because of an unidentified Chrome parsing bug. If
> you remove this part of the test (right at the end), the test passes
> on Chrome;
>=20
>  bin_doc6._attachments["foo.txt"] =3D { stub: true, revpos: 10};
>  try {
>      T(db.save(bin_doc6).ok =3D=3D true);
>      T(false && "Shouldn't get here!");
>  } catch (e) {
>      T(e.error =3D=3D "missing_stub")
>  }
>=20
> It is *not* sufficient to merely comment it out, the test still hangs.
> Interestingly, the presence of this stanza prevents even the first
> line of the test from executing. I confirmed this by building another
> test class and copying attachments.js over incrementally. The oddness
> of this bug was confirmed by doppler on #couchdb.
>=20
> replication.js fails because Chrome has another bug around the common
> defaulting idiom we use. In couch.js we default options and
> options.headers to empty objects if either are undefined, which should
> make the reference to options.headers['Content-Type'] completely safe.
> Not so in Chrome. I added if (!options.headers) alert('oops'); after
> both defaulting lines and it fires on Chrome.  The following patch
> fixes it but I don't think we should apply it;
>=20
> diff --git a/share/www/script/couch.js b/share/www/script/couch.js
> index b7e0e51..7d18939 100644
> --- a/share/www/script/couch.js
> +++ b/share/www/script/couch.js
> @@ -397,8 +397,8 @@ CouchDB.newXhr =3D function() {
> }
>=20
> CouchDB.request =3D function(method, uri, options) {
> -  options =3D options || {};
> -  options.headers =3D options.headers || {};
> +  options =3D typeof(options) =3D=3D 'object' ? options : {};
> +  options.headers =3D typeof(options.headers) =3D=3D 'object' ? =
options.headers : {};
>   options.headers["Content-Type"] =3D options.headers["Content-Type"]
> || options.he
>   options.headers["Accept"] =3D options.headers["Accept"] ||
> options.headers["accep
>   var req =3D CouchDB.newXhr();
>=20
> B.