On Fri, Feb 14, 2014 at 11:29 PM, James Keane <[email protected]<https://mail.google.com/mail/?view=cm&fs=1&tf=1&[email protected]> > wrote:
> I have been running into a few issues w.r.t initial loading... speed and > browser locking due to (client side) script rewriting. > Hi James, sorry for the delay. We'll look into it. So we might be able to align the platforms we're testing on, what platforms are you using? > > I am wondering why scripts are always fully mitigated > (htmlemitter.js:593|1089 & startSES.js:307). What is the point of all of > the SES repairing, if full mitigation needs to be done anyways? Some > clarification on this would help immensely. I feel as if I am lacking some > crucial information here. > The point of the repairing is indeed to avoid parsing and translation for programs that don't need it. And also to be able to run SES standalone without a parser, and therefore without mitigation, when we're willing to live with the unmitigated semantic differences < http://es-lab.googlecode.com/svn/trunk/src/ses/>. > > Also, in the worst-case mitigateSrcGotchas and full program parsing can > happen _three times in a row_. Forgive my notation on this manual stack > trace > > --- > startSES:compileModule() calls mitigateSrcGotchas. > compileModule() also calls securableWrapperSrc() which > calls verifyStrictExpression() > verifyStrictExpression() calls ses.verifyStrictFunctionBody() TWICE > > ses.verifyStrictFunctionBody() could (worst-case) evaluate to > verifyStrictFunctionBodyByParsing() which again calls mitigateSrcGotchas(). > --- > Thanks for catching and reporting this! This behavior is indeed odd and unintended. We'll see what we can do about reducing it. > > For now I will try to use uriPolicy.mitigate to partially resolve this > issue (jquery) but browser locking due to parsing is a serious concern for > me especially on mobile. > > Do you think it would be feasible to optionally support mitigateSrcGotchas > in a webworker? My brief investigation makes me believe only minimal code > changes would be required to make mitigateSrcGotchas a promise. If > mitigateSrcGotchas is a promise then caja.js can load a webworker (if > supported) in place of utility-frame.js and boom, no more browser locking. > This is an interesting direction to explore. But let's get back to it after we investigate the perverse behavior you've identified. Thanks again! -- Cheers, --MarkM -- --- You received this message because you are subscribed to the Google Groups "Google Caja Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
