2006-07-06 19:13:50 David Southwick: * SUMMARY VitalSource Bookshelf fails when registering a new account on Leopard9A213. * STEPS TO REPRODUCE 1. Install Leopard9A214 2. Install and Launch VitalSource Bookshelf 4.0 from http://vitalsource.com/ 3. Click on the "VitalSource Store" in the "Collections" in the left column 4. Click on the "Sign-in" button in the top right corner 5. Click on the "Register" hyperlink 6. Enter new account information (temporary e-mail such as @mailinator.com should suffice) * RESULTS Reports that none of the fields received text (prompts you to enter text for all required fields), and continues to prompt you for account information everytime. No console spew. * REGRESSION Occurs on: M33 (PPC/iMac) running Leopard9A214 M9 (Intel/MacBook Pro) running Leopard9A213 M42 (Intel/MacBook) running Leopard9A210 Does not occur on: M9 running SUChardLondon8J2135a * NOTES • Leopard Must-Not-Break app 2006-07-07 18:12:12 Ryan Dumperth: Did this pass the first sweep? 2006-07-10 15:45:17 David Southwick: Occurs back to 9A192. 2006-07-11 17:27:09 Carol Le: Occurs as far back as 9A99 so far. When launching VitalSource, an error appears before step #3: "The required fonts were not found. Please install the fonts from the VitalSource Bookshelf installer or contact support for assistance." Perhaps this is the cause of the problem? - The install logs show no errors, it says that "Packages report 423 files, 423 actual files written." - When choosing "Customize" from the installer, the "VitalSource Fonts" option is checked by default. 2006-07-12 12:13:44 Carol Le: Broke somewhere between 9A50 and 9A99. 2006-07-12 19:44:34 Carol Le: Broke somewhere between 9A55 and 9A77. 2006-07-24 15:28:20 Carol Le: Regression summary: - Last build that this bug does not occur: 9A57 - Builds 9A58-9A77 do not boot on my machines - Bug occurs in: 9A78+ The problem seems to be caused by WebKit. When swapping in WebKit-412.0.3 to replace WebKit-521, the bug no longer occurs in 9A78. 2006-07-25 11:12:38 Alice Liu: Safari BRB Reviewed <rdar://problem/4616860>
3/27/07 6:11 PM Adele Peterson: It would be really good to understand how this worked in Safari 2.0. Let's check out and debug on the 2.0 branch. When you hit the "register" button, I see this in the bt: #0 -[WebFrame loadRequest:] (self=0xec3b70, _cmd=0x90ab7174, request=0x16d98080) at WebFrame.mm:729 #1 0x00049a14 in -[MiniRickController submitButtonClicked:] () The request is this: <NSURLRequest https://minirick.vitalbook.com/minirick/register.do?&mc=0016CB8A54E6&mn=adelembp&appName=VitalSource%20Bookshelf> So...the request clearly doesn't have any form data in it. And the normal form submission process is not occurring. Since we don't have the source of the app, I think the next step is to debug a working version. 3/28/07 12:01 PM Adele Peterson: [MiniRickController submitButtonClicked:] calls [WebView stringByEvaluatingJavaScriptFromString:] with this script string: "return document.forms[0].elements.length" The JS execution has an error, and the app thinks that there are no form elements, so it doesn't construct a good url to send to the registration page. Here is the error (from interpreter.cpp: 379): [13316] line 1: SyntaxError: Invalid return statement. 3/28/07 12:49 PM Adele Peterson: After talking with Maciej, we realized that return values aren't allowed outside of functions. In Safari 2.0, we didn't check for this, and we allowed it. We should add a workaround for the app, and evangelize to get them to change their code. They could just submit the form itself (which is what happens when you hit "Enter") instead of constructing a url with the form values. 3/28/07 2:05 PM Adele Peterson: Committed revision 20555.