From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=91.121.71.147; helo=nautica.notk.org; envelope-from=asmadeus@notk.org; receiver= Received: from nautica.notk.org (nautica.notk.org [91.121.71.147]) by hurricane.the-brannons.com (Postfix) with ESMTPS id 0707E779FB for ; Sat, 13 Jan 2018 08:24:10 -0800 (PST) Received: by nautica.notk.org (Postfix, from userid 1001) id A42D7C009; Sat, 13 Jan 2018 17:27:30 +0100 (CET) Date: Sat, 13 Jan 2018 17:27:15 +0100 From: Dominique Martinet To: Chuck Hallenbeck Cc: Karl Dahlke , edbrowse-dev@lists.the-brannons.com Message-ID: <20180113162715.GA16048@nautica> References: <20180013091101.eklhad@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [Edbrowse-dev] amazon and its JS X-BeenThere: edbrowse-dev@lists.the-brannons.com X-Mailman-Version: 2.1.24 Precedence: list List-Id: Edbrowse Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jan 2018 16:24:11 -0000 Hi all, On my end I cannot log in either, using duktape's master, but I've been playing a bit with duktape's debugging. One thing I find odd is that the loading time for www.amazon.com (not the sign in page) seems to vary greatly from one run to another. Sometimes it loads in tens of seconds (slow but bearable), but sometimes it takes as much as five minutes to load, and I'd be hard pressed to say what's different... I was blaming the duktape's debugger for speed but it could be something else entierly. On the other hand, I have implemented some of the duktape's debugging protocol into edbrowse, you will need to build with a checkout of duktape's and you need to edit duk_config.h to make at least DUK_USE_DEBUGGER_SUPPORT into #define, then pull in my master's branch (https://github.com/martinetd/edbrowse.git) So far I don't do anything with debugger except listening to events, duktape is kind enough to tell us about all 'throw' exceptions in the js code even if they are caught -- without debugging we can only see the uncaught ones, maybe some caught exceptions can be a hint. I've got to say though that amazon's code really is a pain to debug with the obfuscated variables though... So far I've had these errors (without demin here so don't trust line numbers too much) uncaught throw: ReferenceError: identifier 'querySelectorAll' undefined (line 1417) uncaught throw: TypeError: undefined not callable (property 'appendChild' of [object Object]) (line 887) caught throw: ReferenceError: identifier 'Canvas' undefined (line 1227) caught throw: TypeError: cannot read property 'indexOf' of undefined (line 13) uncaught throw: TypeError: undefined not callable (property 'setAttribute' of [object Object]) (line 18) uncaught throw: TypeError: undefined not callable (property 'setAttribute' of [object Object]) (line 17) and in a timer (I removed prints when in timer in last commit): caught throw: TypeError: undefined not callable (property 'getAttribute' of [object Object]) (line 27) I have only walked through the very first of these : querySelectorAll seems to be invoked from document (e.g. document.querySelectorAll()) modulo tons of obfuscation. I thought this would be easy to fix by just adding a line in startwindows.js like this : document.querySelectorAll = querySelectorAll But that doesn't seem to work because querySelectorAll is defined in third.js, not sure how to proceed here. It took me a long time just to figure that querySelectorAll was looked at from document though, mostly because of amazon's code, but I think stopping in the context of the duktape debugger might help a bit. We could have the js call stack at the time of the throw for example (might not be of much help for amazon), or we could dump local variables. See https://github.com/svaarala/duktape/blob/master/doc/debugger.rst for available functions, anything under "Commands sent by debug client" would be available with a bit more glue. Initially I wanted to just let us run the jdb prompt from buffer.c whenever a throw came in, but we can't because this assumes it can process js normally (timers etc) and I think this will hang while debugger is paused, we need to use the debugger eval at this point so I might make a second jdb on that side if it works well. -- Dominique