Re: [webkit-dev] impending changes to how new-run-webkit-tests prints/logs stuff
Another possibility is --extraverbose. That is more verbose (!), but perhaps more obviously related to --verbose than --debug is. John On Jul 31, 2012, at 7:28 PM, Ryosuke Niwa wrote: Let's rename --verbose --verbose to --debug at least. I'd also prefer renaming --details to --trace or something because --details sounds less detailed than --debug but I'm not strongly opinionated about this. - Ryosuke On Tue, Jul 31, 2012 at 7:09 PM, Dirk Pranke dpra...@chromium.org wrote: On Tue, Jul 31, 2012 at 7:02 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Jul 31, 2012 at 6:59 PM, Dirk Pranke dpra...@chromium.org wrote: On Tue, Jul 31, 2012 at 6:36 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Jul 31, 2012 at 6:29 PM, Dirk Pranke dpra...@chromium.org wrote: I'm finally getting around to cleaning up the byzantine mass of options in new-run-webkit-tests that controls what gets printed to stderr and stdout during a test run. The patch is posted in https://bugs.webkit.org/show_bug.cgi?id=92432. To quote the changelog: [All of the --print X,Y,Z options are] replaced by five printing modes/options: 1) by default, we print some configuration information, errors, warnings, and a progress bar. We didn't use to print the configuration information by default, and I've found that (a) it's really useful and (b) most people didn't know about it. However, if you don't want that output, use ... 2) if --quiet is passed, we don't print the configuration information (this was the default before) 3) if --verbose is specified once, you will get a one-line-per test summary in addition to the default output of (1). This is close to the --verbose mode from ORWT and is probably more useful than the older form of --verbose, which printed out a lot more debug-type stuff. To get the debug-type stuff ... 4) if --verbose is specified twice, you get the old-style debug log output And, if you used to use the obscure but occasionally really helpful --print trace-everything flag: 5) if --details is specified, you get the per-test details you used to get with --print trace-everything or --print trace-unexpected. --details handling is largely independendent of --quiet/--verbose. We've still got too many --verbose/--details options. Can we just combine two --verbose and --details or remove one of them and call it --debug? I'm not sure if I understand your suggestion. Are you suggesting we call --details --debug instead? or have --verbose --verbose be replaced by --debug? My suggestion is to merge --verbose --verbose and --details into one option: --debug. Right, I wouldn't want to do that; it would make the already-too-big bot output 6x bigger, I'm guessing. We definitely don't want --details to be enabled by default either interactively or on the bots; it logs way too much if you're running a lot of tests. I also personally would not want to have to slog through the debug output to extract the stuff that --details will print. I would be fine with changing '--verbose --verbose' to '--debug', but I'm not sure if that's either much of an improvement or enough to make you happy? So we need to have --verbose --verbose separately from --verbose and --details to be used on bots? Why don't we get rid of single --verbose then? ap@ and others have requested a single --verbose that is closer to what ORWT used to do (bug 88702); something more than what we get by default, but less verbose than either what --details or --verbose/--debug would be. -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Clearing a textfield's 'autofilled' status on change, not focus
It seems reasonable to me that the autofilled property is only cleared when the text is modified by the user. Since it is a visible change in the behavior, there's always a chance that it will not sit well with everyone and we might eventually have to allow for both behaviors somehow. But it seems like a small enough behavior change that it's unlikely that anyone will care strongly about it. John On May 11, 2010, at 11:22 AM, Jens Alfke wrote: HTMLInputElement's 'autofilled' property is cleared when the field gets focused[1]. This has the visible effect of clearing the pale-yellow background color to white. Safari only seems to use this background-color highlighting for autofill of names, emails, addresses, etc., but Chrome also uses it for autofilled usernames and passwords in login forms. In login forms at least, the current UI seems wrong[2]. That's partly because the form is often filled in automatically when the page is loaded (so a script that focuses a field on page load can end up clearing the highlight); and partly because the password is unreadable, so it's impossible to tell from inspection whether it's still autofilled or edited by the user. Are there strong feelings in favor of the current UI, or would it be OK to change it overall so that the autofilled property is only cleared when the text is user-modified? If the current UI needs to stay the same, could we compromise by changing the behavior of the property in login forms only, since such a change would have no visible effect in Safari? —Jens [1] See HTMLInputElement::handleFocusEvent, currently line 753. [2] http://code.google.com/p/chromium/issues/detail?id=38386 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] How to add a progress bar of page loading with webkit?
I'm not sure where you are looking. This is from WebView.h: /* @discussion Notifications sent by WebView to mark the progress of loads. @constant WebViewProgressStartedNotification Posted whenever a load begins in the WebView, including a load that is initiated in a subframe. After receiving this notification zero or more WebViewProgressEstimateChangedNotifications will be sent. The userInfo will be nil. @constant WebViewProgressEstimateChangedNotification Posted whenever the value of estimatedProgress changes. The userInfo will be nil. @constant WebViewProgressFinishedNotification Posted when the load for a WebView has finished. The userInfo will be nil. */ extern NSString *WebViewProgressStartedNotification; extern NSString *WebViewProgressEstimateChangedNotification; extern NSString *WebViewProgressFinishedNotification; ,,, /*! @method estimatedProgress @discussion An estimate of the percent complete for a document load. This value will range from 0 to 1.0 and, once a load completes, will remain at 1.0 until a new load starts, at which point it will be reset to 0. The value is an estimate based on the total number of bytes expected to be received for a document, including all it's possible subresources. For more accurate progress indication it is recommended that you implement a WebFrameLoadDelegate and a WebResourceLoadDelegate. */ - (double)estimatedProgress; John On Oct 9, 2009, at 1:55 AM, Jickae Davis wrote: Well, I checked the WebView.h, and didn't find the estimateProgress method and the three associated notifications. Then I searched them in the chrome's whole solution, didn't get any clue too. 2009/9/28 John Sullivan sulli...@apple.com The Chrome and Safari teams have chosen not to display approximate progress bars for user interface design reasons. You can implement a progress bar for a WebKit-based browser by using the -estimatedProgress method in WebView.h and the associated notifications WebViewProgressStartedNotification, WebViewProgressEstimateChangedNotification, and WebViewProgressFinishedNotification. Note that any such progress bar (in any web browser, WebKit-based or not) is only an approximation, because as a page loads resources, it might discover additional resources that need to be loaded, so the page cannot know in advance how much more there is to load. John On Sep 28, 2009, at 12:14 AM, Jickae Davis wrote: I'm wonderring why Chrome and Safari don't add a progress bar which indicates the progress of loading a html page. I took a look at all the ViewMsg and ViewHostMsg in Chrome's src, and didn't find anything related. So, is that unimpossible to create such a progress bar? If it's not so hard, how to achieve that? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Changes to prepare-ChangeLog
On Jul 2, 2009, at 12:40 AM, Eric Seidel wrote: Agreed. Although, Darin Adler is about the only person I ever see fill in per-file/per-function information. :) Darin is certainly more conscientious about this than most people, but a quick glance at WebCore's ChangeLog shows that many other people also fill in per-file/per-function information. I've found this information invaluable on many occasions when tracking down why a change was made, not just when. John ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New simplified patch review interface for bugs.webkit.org
This is a huge improvement -- thanks Adam! John ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebHistory problems (how to load Safari history objects)
Safari does not have a feature like this, sorry. John On Jun 7, 2008, at 12:45 AM, uru lama wrote: Thank you, for the info :D So, I guess my next question is: is it possible to tell Safari to store every page, not just URL but also the content, the user visits to a file (I hoped that this would be an WebHistoryItem object)? UruLama On Fri, Jun 6, 2008 at 11:25 PM, Mark Rowe [EMAIL PROTECTED] wrote: On 06/06/2008, at 01:15, uru lama wrote: Hi, all. I would like to load webhistory objects stored in the Safari history directory (~/Library/Caches/Metadata/Safari/History). However, loading from file using the NSURL and WebHistory loadFromURL method does not work since WebHistory object is always empty and the method returns a NO value. BOOL res = [whist loadFromURL:nsurl error:histerror]; Can anyone help me how to load these webhistory objects? The files in ~/Library/Caches/Metadata/Safari/History are not WebHistory objects, though I can see why the file extension may have led you to believe they were. These files are extra metadata that Safari keeps around for sake of Spotlight, and are not something that you should work with directly. - Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebHistory problems (how to load Safari history objects)
Those files are not Safari's history. They are an implementation detail of how Spotlight works with Safari's history. Safari's history is stored in ~/Library/Safari/History.plist. John On Jun 6, 2008, at 1:15 AM, uru lama wrote: Hi, all. I would like to load webhistory objects stored in the Safari history directory (~/Library/Caches/Metadata/Safari/History). However, loading from file using the NSURL and WebHistory loadFromURL method does not work since WebHistory object is always empty and the method returns a NO value. BOOL res = [whist loadFromURL:nsurl error:histerror]; Can anyone help me how to load these webhistory objects? TNX, Uros. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Error when calling a WebDataSource's subresources method
It's a bug; the API shouldn't be throwing exceptions. Please file a bug at http://bugs.webkit.org. John On Dec 15, 2007, at 2:03 AM, Martin wrote: Hi, When I call the following method: [dataSource subresources] from inside the following method: - (id)webView:(WebView *)sender identifierForInitialRequest: (NSURLRequest *)request fromDataSource:(WebDataSource *)dataSource of my WebResourceLoadDelegate, I get the following error (the error occurs for 98 out of 105 calls to the previous method for a specific webpage): *** WebKit discarded an uncaught exception in the webView:identifierForInitialRequest:fromDataSource: delegate: NSInvalidArgumentException *** -[NSCFArray insertObject:atIndex:]: attempt to insert nil Is this normal because I'm not supposed to ask for the subresources until everything is loaded? Or is it a bug? Many thanks, Martin. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The mysterious IconDatabase
Safari has no logic of its own about which icon goes with which site; it relies on the icon database for this knowledge. Safari does have a little logic to pevent the icon in the URL field from flashing back and forth between a generic and non-generic icon as you type in a URL. John On Sep 18, 2007, at 9:53 AM, Patrick Hanna wrote: So I do *not* have the 25557 patch and that will help. What tools are in place to accomplish the behavior that I want? Is this something that Safari does? I would love to be able to show the google.com icon until I know the real icon but I don't know how to use the IconDatabase to accomplish this. For one thing, I don't want to assume that google.com/search?hl=whatever uses google.com/ favicon.ico. I would rather have either the FrameLoader or the IconDatabase tell me early on what icon or icon url it *thinks* is correct until the real url is known. Pat On Sep 18, 2007, at 12:46 PM, Brady Eidson wrote: Hi Patrick, Could you give a little more context? Are you using ToT WebKit? On Sep 18, 2007, at 9:27 AM, Patrick Hanna wrote: Load www.google.com, FrameLoaderClient::dispatchDidReceiveIcon is called. IconDatabase::iconForPageURL returns an icon, this is perfect. Right Load www.google.com/search?hl=enq=some_querybtnG=Google+Search, dispatchDidReceiveIcon is *not* called. In current ToT WebKit, it should be called for every single page load. Specifically as of revision 25557 (http://trac.webkit.org/projects/webkit/changeset/25557 ) If I call iconForPageURL *before* the load is finished, I won't get an icon unless I have already visited the site. If I call it after the load has finished, this could potentially show the wrong icon until the load has finished. This is expected - until you visit a site, the icon database doesn't know what icon belongs to the site. You might think it quite obvious that www.google.com/search?hl=enq=some_querybtnG=Google+Search should use the google site icon, but www.google.com/search?hl=enq=some_querybtnG=Google+Search might manually link to www.foobar.com/favicon.ico in it's head element - we simply don't know until the sight has loaded once. Therefore, until you do actually load the site, iconForPageURL(www.google.com/search?hl=enq=some_querybtnG=Google+Search ) should return the default icon. Here is the behavior that I want: Load www.google.com, show the default icon until the google favicon is loaded and dispatchDidReceiveIcon is called. Load www.google.com/search?hl=whatever , show the google favicon unless dispatchDidReceiveIcon is called. Load www.someothersite.com, show the default icon until dispatchDidReceiveIcon is called. How can I accomplish this behavior when the IconDatabase doesn't know about pageUrls- iconUrls until *after* the load has completed? To accomplish this behavior you'll have to do a little work. As I said above, it is impossible to know for sure which icon belongs to a site until you've visited that site once. But I think it's quite reasonable if an API client wants to make assumptions by itself and ask for a different icon. Maybe what you're going for here is to have your API client run it's own logic that says Okay, I don't know the icon for http://www.google.com/search?hl=enq=some_querybtnG=Google+Search , but I do know the icon for http://www.google.com/, so I'll show that icon instead until I know the http://www.google.com/search?hl=enq=some_querybtnG=Google+Search icon for sure And the tools *are* in place to accomplish that now. Hope this helps, Brady Safari/WebKit Engineer Thanks, Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The mysterious IconDatabase
On Sep 18, 2007, at 10:25 AM, Patrick Hanna wrote: I have discovered that I have an IconDatabase that is older than the new multi-thread database if that is any help. If Safari has no extra knowledge, how does it decide to display the google icon for www.google.com/search before visiting the site but after visiting www.google.com? The same applies for visiting news.google.com, images.google.com, maps.google.com, etc. I tried setting a breakpoint on iconForPageURL but it just returned NULL. Pat I can't reproduce this. This is what I see: 1. use Reset Safari to clear the icon database 2. type http://www.google.com into URL field and hit Return -- custom icon appears after page loads 3. type http://www.google.com/search into URL field -- no custom icon 4. hit Return -- custom icon appears during/after page load 5. type http://news.google.com into URL field -- no custom icon 6. hit Return -- custom icon appears during/after page load John ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
