From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out.smtp-auth.no-ip.com (smtp-auth.no-ip.com [8.23.224.60]) by hurricane.the-brannons.com (Postfix) with ESMTPS id A260377BBB for ; Sun, 2 Jun 2019 00:10:41 -0700 (PDT) X-No-IP: carhart.net@noip-smtp X-Report-Spam-To: abuse@no-ip.com Received: from carhart.net (unknown [99.57.137.251]) (Authenticated sender: carhart.net@noip-smtp) by smtp-auth.no-ip.com (Postfix) with ESMTPA id 1F33137FB7D; Sun, 2 Jun 2019 00:10:39 -0700 (PDT) Received: from localhost (kevin@localhost) by carhart.net (8.15.2/8.15.2) with ESMTP id x527AX0g176339; Sun, 2 Jun 2019 00:10:35 -0700 Date: Sun, 2 Jun 2019 00:10:33 -0700 (PDT) From: Kevin Carhart To: Karl Dahlke cc: edbrowse-dev@lists.the-brannons.com Subject: Re: [edbrowse-dev] window.location.search and String.search In-Reply-To: <20190502024317.eklhad@comcast.net> Message-ID: References: <20190502024317.eklhad@comcast.net> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) X-BeenThere: edbrowse-dev@edbrowse.org List-Id: Edbrowse Development List MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Oops, you're right, I should have given a file and line number! If you load https://www.baseball-reference.com/players/, it's in one of the advertising js files, pubads_impl_2019052302.js at line 1854 after demin. I don't know if it's responsible for inhibiting content from loading such as Players, but it's the first runtime that occurs. Hooray, first piece of find & fix that would probably not have been coherent to isolate and work on without the breakpoint! On Sun, 2 Jun 2019, Karl Dahlke wrote: > I guess you would have to show me where the location.search(stuff) as a function is, because I find it as a string all over, even in the baseball site. > cloud.js lines 42, 589, 1551, 6062, etc. > If you stretch your mind to the limit you could imagine the getter returning a function that is string.match but it has a toString() function that is the string you want, > so if the code coerces it to a string it will be right, but that's the only way, > and most of the time the code doesn't coerce it to a string so it will be an object and blow up. > So no you can't have your cake and eat it too. > More likely there's something wrong with the parameters being passed in, > like maybe the location object should have been coererced to string before it was passed. > Anyways I'd have to look at it for real. > > Karl Dahlke >