Re: [webkit-dev] Implementing the device element
Hi, On 2011-02-09 22:10, Leandro Graciá Gil wrote: So, does that mean that a WebCore platform-independent code is going to determine if a new device handler should be created? I think that some UAs may like to, for example, keep a track of trusted pages for specific types of devices to determine if such a handler should be created. And that is not likely to be implemented in the same way by all the different platforms even if they intend to perform a set of basic common security steps. I completely agree with you that the behaviour should be consistent across platforms, especially the security and privacy aspects, but I don't think that forcing the common code to use available device lists is the way to do it. If we want a consistent behaviour we should ask for it in the specification and leave the implementation specific details open, not the other way around. Yes, the platform independent code in the device element will determine if a selection has been made, or altered, in the list of available devices Provided by the platform. Before passing it to the device element, the list can be filtered by the platform to exclude some entries for whatever reason. Selections can also be automatically applied without showing the Device selector based on, e.g., stored preferences. The device element will examine the list for selection changes to determine if a new device handler should be created (and a change event dispatched). Consider the following example: 1. The user clicks the device element button and a list of devices is presented. 2. The user selects a webcam in the list and clicks OK. *A new Stream is created* 3. The user once again clicks the device element button and the list is presented with the webcam selected from before. 4. The user clicks OK. *No new Stream is created* 5. The user once again clicks the device element button and the list is presented with the webcam selected from before. 6. The user selects a microphone in the list and clicks OK. *A new Stream is created* This is the behavior that should be consistent between ports. One important point that a selection-based design misses is that potentially many devices, if not all, will require exclusive access to them. Let me give a example. We have two different pages with device elements. First, a user selects some device (e.g. a microphone) in the first page, but the page makes no use of it for the moment and hence the real connection is not performed. Minutes later and without closing the first page, the same user selects the same device from before on the second device element (if you have only one microphone and an average user this could be very easy to happen) but this page also makes no use for it at that moment. What happens if for example the first page starts making use of the device and causes the connections on the second page to fail? This is almost for sure not the behaviour that the user is expecting or wanting. It will be up to the device handler API (e.g. Stream) and its potential consumers to handle any errors that may occur. Exclusiveness for certain types of devices being one type of error. Another error occurs when a peripheral device is disconnected while in use. Even if you have established a connection to the device via the device element, handling such an error in the device handler API is still required since it is not possible to revoke a device handler instance. If we again take input type=file and the File API as a model, there you select a filename from a list and get a File object that represents the file. The file itself can be removed from disk but the File object still exists. When you then attempt to use a FileReader on the File it will fail. Regarding exclusiveness for Stream objects, we don't have that limitation in our implementation. It is possible to select the same webcam in several device elements. Yes, you're right on this. I pointed out in my last email that I don't think that there is any problem in having some platform specific code in WebCore as long as any platform can choose to use it or to easily delegate this task to its own WebKit implementation. Sorry if my proposed class diagram mentioned communicating with WebKit as it's not necessarily the case. We have already fixed this for the new diagrams. Do you see anything in our implementation that could not be easily delegated? As I said before, I would be happy to make any changes that would be required to implement the platform specific parts for Chromium. BR Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Aligning User Agent Header changes
Hi, QtWebKit is considering dropping the language tag part of the User Agent string - following Firefox (http://hacks.mozilla.org/2010/09/final-user-agent-string-for-firefox-4/). I think the WebKit community did a reasonable job at aligning the User Agent string for WebKit based products and I was hoping that we could continue this good habit, so I was wondering what other ports/products would think of this change. If there is interest we could turn this thread into a wider discussion and consider other User Agent string changes (e.g. dropping U; for encryption); my immediate interest is only to deal with the language tag part. Thanks, Laszlo ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CSS cache and unfired events.
Hello again. Regarding the events firing, and after some tests, it appears that, using the TryItYourself of the page http://www.w3schools.com/jsref/event_onunload.asp I followed an advised simple routine: -Open TryitYourself page in a new thumb -Edit and click me button always works but -Close the newly created thumb happens to... catches unload event on: Safari5.0.3 Firefox3.6.13 (MAC SNOW LEOPARD) Firefox3.6.13 (WINDOWS 7) unload evt IS NOT CATCHED on: Opera11.01 Chromium11.0.666.0 (MAC SNOW LEOPARD) Safari5.0.3, Chromium9.0.584.0 Opera11.01 (WINDOWS 7) (Safari doesn't react the same whether it runs on OSX or 7) The event seems to be lost or not sent on page closure on most of these browsers (webkit ones too) or, at least, not catchable by any process after sending (maybe some precedence issue in the page's closing steps). Thanks. De : webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev-boun...@lists.webkit.org] De la part de Frédéric Lefebvre Envoyé : mercredi 9 février 2011 18:34 À : webkit-dev@lists.webkit.org Objet : [webkit-dev] CSS cache and unfired events. Hello. I'm currently working on a Webkit interface using an HTMLview filled with YUIlayout panels including an HTMLdocument to edit within. Once a change has been made to the HTMLdocument, we save the whole stuff in both CSS and HTML physical files. When reopening the interface, the HTML file is physicaly accessed but not the CSS and image files included in the HTML. The cache prevails. Primary effect is that, though the HTML contents seem to be correctly brought back (from cache indeed), the styles are not up to date. Secondary effect is, on reload call, that the styles are updated but the HTML contents disappear. I would like to assure the cache is correctly flushed on page closure, but it appears that neither unload nor pagehide event is fired upon Page::~Page run in the Webkit core. The page destructor closes backforward list then calls the PageCache::remove without finding any cached page for the HistoryItem passed and that's it. How could I ensure, from higher layers, that the CSS cache and HTML of the edited HTMLdocument are surely flushed from cache and not retrieved on subsequent calls without adding ?val=random tricks in the URLs of DOM elements. Obviously no-cache, must-revalidate and all these obsolescence tricks are of no interest here since, even if the document has to be no-cache accessed on loading, we should be able to edit an ultimately cachable document. Any advice or clue welcome. Thanks. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Aligning User Agent Header changes
On Thu, Feb 10, 2011 at 7:32 AM, laszlo.1.gom...@nokia.com wrote: QtWebKit is considering dropping the language tag part of the User Agent string - following Firefox ( http://hacks.mozilla.org/2010/09/final-user-agent-string-for-firefox-4/). I think the WebKit community did a reasonable job at aligning the User Agent string for WebKit based products and I was hoping that we could continue this good habit, so I was wondering what other ports/products would think of this change. Several of us on the Chromium side have mentioned this to each other. We're definitely interested in simplifying the UA string, especially if it can be done in concord with other browsers. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Aligning User Agent Header changes
10.02.2011, в 07:32, laszlo.1.gom...@nokia.com laszlo.1.gom...@nokia.com написал(а): QtWebKit is considering dropping the language tag part of the User Agent string - following Firefox (http://hacks.mozilla.org/2010/09/final-user-agent-string-for-firefox-4/). I think the WebKit community did a reasonable job at aligning the User Agent string for WebKit based products and I was hoping that we could continue this good habit, so I was wondering what other ports/products would think of this change. I'm not aware of specific reasons to keep the language (locale?) in user agent string. Seems worth trying to see if any sites break. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Getting CC-ed on webkit.org/new-inspector-bug
On Thu, Feb 10, 2011 at 9:16 AM, Antonio Gomes toniki...@gmail.com wrote: It was very common to use this approach on bugzilla.mozilla.org, with each component in the system having its own dummy email address auto-added. This allows developers to subscribe / unsubscribe from receiving email for various components in the bug system. I would *very* much support that. -- --Antonio Gomes What Mozilla does is they set the QA Contact field to an email address of the form component@product.bugs. We don't have that field in bugs.webkit.org, so we'd need to either add it, some other field, or maybe we could just get by with adding this email address to the CC list. Using the QA Contact was a convenient hack for Mozilla because 1) they don't need the field for anything else and 2) the email preferences have a separate column of options for following the QA Contact. I have no idea what it would take to setup something like this for bugs.webkit.org, but I'm hoping that those who do can chime in with their thoughts. Regards, -Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Getting CC-ed on webkit.org/new-inspector-bug
10.02.2011, в 10:58, Darin Fisher написал(а): What Mozilla does is they set the QA Contact field to an email address of the form component@product.bugs. We don't have that field in bugs.webkit.org, so we'd need to either add it, some other field, or maybe we could just get by with adding this email address to the CC list. One thing that can probably be easily done is changing default assignee for Inspector bugs. People could then watch this e-mail address. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Web Inspector blog post draft
For those who are interested in this, I've included the draft inline below. Mihai Web Inspector: Styles Enhanced http://webkit.org/blog/?p=1463Posted by *Alexander Pavlov* on Wednesday, February 9th, 2011 at 9:43 am During the past months, we’ve been working hard to improve the CSS editing experience for the Web Inspector users. Now, we are happy to provide you with an update. Style Presentation Did you find yourself in a situation when you entered a big and complex gradient definition for yourbackground property, and it disappeared once you hit Return? The reason was that the Styles sidebar showed the style content exactly the way the browser understood it, and if it did not understand it, inspector showed nothing. This has now changed: inspector shows all the properties declared in a style, and if the browser does not understand a property name or value, the respective property is denoted by an exclamation mark ([image: warning]) next to its name. Still, you can edit (or remove) these properties along with the regular ones. On a related note, Web Inspector can now show the colors in property values exactly as they are written in the CSS – just use the “As Authored” presentation option accessible via the Gear menu. Editing Styles Based on the feedback from our users, we have improved the editing of CSS properties. Two separate fields are now used for a property name and value instead of one, and you can navigate between them (as well as between properties) back and forth with the Tab/Shift-Tab or Return keys. Available keywords for property values are suggested as you type, and can be auto-completed using the End or → keys, just like in the console view. The previous/next suggestions can be selected with the ↑ and ↓ keys. If you wish to accept the current suggestion and move on to another field, use the Tab/ Returnkeys. Additionally, you can paste a compound “name: value” property text into the name field, and inspector will break it up into “name” and “value”, putting each in its own field for you. Persisting Changes Every time you modify a style from an external style sheet, the respective resource text is updated in the Resources panel (this feature is work-in-progress) and the history is tracked for such style sheet resources while inspector remains open. Select any resource revision to see its differences from the original one, highlighted line-wise. A textual resource node (including stylesheet revisions) can be drag and dropped onto most text editors to export the specific resource content. Things You Might Not Know Please let us take this opportunity to tell a few things you might not know. While in the Styles pane, you can: - …add a new property to an editable style either by double-clicking in the blank space of the lines with opening and closing braces, or by hitting Tab while editing the last property value. - …add a new rule by selecting the “New Style Rule” item in the Gear menu. - …click a link in a property value (say, background-image) to navigate to the respective resource in the Resources panel. - …click a color swatch next to a color value to cycle through available color representation formats. We are currently experimenting with more improvements to style handling within Web Inspector. Stay tuned and check back often! On Wed, Feb 9, 2011 at 11:27 AM, Patrick Mueller pmue...@muellerware.org wrote: I'm logged in (as near as I can tell - link at the bottom says Log out), and still get the error. I don't have posting rights to the blog, nor do I want them. On 2/9/11 2:20 PM, Adele Peterson wrote: You have to be logged into the blog to read drafts. -- Patrick Mueller - http://muellerware.org ___ 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] Getting CC-ed on webkit.org/new-inspector-bug
It seems like it'd be nice to be able to watch bugs that are assigned to someone too though. On Thu, Feb 10, 2011 at 11:18 AM, Alexey Proskuryakov a...@webkit.org wrote: 10.02.2011, в 10:58, Darin Fisher написал(а): What Mozilla does is they set the QA Contact field to an email address of the form component@product.bugs. We don't have that field in bugs.webkit.org, so we'd need to either add it, some other field, or maybe we could just get by with adding this email address to the CC list. One thing that can probably be easily done is changing default assignee for Inspector bugs. People could then watch this e-mail address. - WBR, Alexey Proskuryakov ___ 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] EventTarget Changes Causes Safari Launch Problems
On Wed, Feb 9, 2011 at 8:03 PM, Alex Milowski a...@milowski.org wrote: In a recent set of experiments in changes to XML processing, I added a new EventTarget class called XMLReader. As such, I had to add a toXMLReader() method to the EventTarget class. Previously, this has worked well but now, after updating this code to the latest trunk, I have a problem launching Safari (it crashes right at startup without even showing a window). It is unclear to me why it would have worked before but now does not. I've narrowed my troubles down to what I think is a virtual table change relating to the class structure although I really haven't proven that. If I hack my way around the need for the toXMLReader() method on EventTarget, doing some very unsavory things, the latest trunk with my changes and the latest version of Safari work fine. Any ideas why, within the last month, this would all change? Was I just lucky before? Grumble. This is a complete mystery but I think something in the build is trying to be too smart. It didn't make sense that code that I built (WebKit) would have a wrong virtual table for other code that I just build (WebCore). After leaving out my final change to the EventTarget class, I added in my method again, removed the build directory, and rebuilt. I can now launch safari. In the last couple days, I have done the same process of deleting the WebKitBuild directory, starting over with a clean build, and safari crashes. Is there something else that I should delete to make sure everything is in sync? Pre-compiled headers? I think the WebKit code built was out of sync with the WebCore changes I made but I can't see why that would be when I removed the build directory and ran the build-webkit script. That should have built everything correctly since I started from scratch. Anyway, things are back to normal. I'll put the paper and the patch up somewhere nearer to when I present this at XML Prague in late March. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Plugin Troubles with Local Builds vs. Nightly Build Differences
I've been trying to get some plugins to work with a locally built version of WebKit without much success. They do work in the nightly build and so that makes me think that my configuration or build is somehow different. I've noticed that when I use Tools/Scripts/run-safari, the plugin is launched using: /System/Library/Frameworks/WebKit.framework/WebKitPluginAgent instead of my locally build WebKit.framework from my build directory. In fact, the 'WebKitPluginAgent' executable isn't there in my locally built version of 'WebKit.framework'. Also, I would like to build a version of 'WebKit.app' like the nightly build. The nightly build works with these plugins. I was able to run Tools/BuildSlaveSupport/build-launcher-app but that put the frameworks in the wrong spot and the sparkle framework wasn't built. I was able to move things around a bit to get a working app but plugins still do not work. Is there a correct sequence of build steps to reproduce what the nightly build does to build WebKit.app such that WebKitPluginAgent also gets built (and hopefully plugins work)? -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Plugin Troubles with Local Builds vs. Nightly Build Differences
Alex: See my bugs here: https://bugs.webkit.org/show_bug.cgi?id=49146 https://bugs.webkit.org/show_bug.cgi?id=37507 Basically, updated versions of the required executables aren't part of the open source repository. Workaround: Copy the WebKitPluginAgent and WebKitPluginHost to your locally built WebKit.framework from a recent nightly. Jon On Feb 10, 2011, at 6:28 PM, Alex Milowski wrote: I've been trying to get some plugins to work with a locally built version of WebKit without much success. They do work in the nightly build and so that makes me think that my configuration or build is somehow different. I've noticed that when I use Tools/Scripts/run-safari, the plugin is launched using: /System/Library/Frameworks/WebKit.framework/WebKitPluginAgent instead of my locally build WebKit.framework from my build directory. In fact, the 'WebKitPluginAgent' executable isn't there in my locally built version of 'WebKit.framework'. Also, I would like to build a version of 'WebKit.app' like the nightly build. The nightly build works with these plugins. I was able to run Tools/BuildSlaveSupport/build-launcher-app but that put the frameworks in the wrong spot and the sparkle framework wasn't built. I was able to move things around a bit to get a working app but plugins still do not work. Is there a correct sequence of build steps to reproduce what the nightly build does to build WebKit.app such that WebKitPluginAgent also gets built (and hopefully plugins work)? -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ 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] Plugin Troubles with Local Builds vs. Nightly Build Differences
On Thu, Feb 10, 2011 at 3:55 PM, Jon Shier j...@jonshier.com wrote: Alex: See my bugs here: https://bugs.webkit.org/show_bug.cgi?id=49146 https://bugs.webkit.org/show_bug.cgi?id=37507 Basically, updated versions of the required executables aren't part of the open source repository. Workaround: Copy the WebKitPluginAgent and WebKitPluginHost to your locally built WebKit.framework from a recent nightly. Great. The workaround worked! Thanks! I've wasted a lot of time tracking this down. We should really try to get this updated so a local build works with plugins. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Preload Scanner in WebKit
Hi, While trying to understand preload scanning in WebKit code, I got to know that it only starts when HTMLTokenizer encounters JavaScript. Am I right in concluding so? If yes, why it's not started if when CSS files or other sub-resources are encountered first. Is there any particular reason for this?? Thanks for any help. Regards, ROSE-nd-ASH, ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Preload Scanner in WebKit
On Thu, Feb 10, 2011 at 11:09 PM, ROSE-nd-ASH rosen.d...@gmail.com wrote: While trying to understand preload scanning in WebKit code, I got to know that it only starts when HTMLTokenizer encounters JavaScript. Am I right in concluding so? If yes, why it's not started if when CSS files or other sub-resources are encountered first. Is there any particular reason for this?? We run the preload scanner when the regular parser is blocked on the network. CSS and other sub-resources don't block the main parser whereas scripts do. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
