[webkit-dev] Segmentation fault (Core dump) while running Gtk launcher
Hello webkit community, I just want to ask what could be the possibility that is giving the following error while running GTK launcher in debug mode: oxb4049401/usr/lib/i386-linux-gnu/libgio-2.0.so.o(+0x524a1)[oxb4049401] Segmentation fault (Core dump) Hope to get a satisfactory response. Thanks Regards Navanshu ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Segmentation fault (Core dump) while running Gtk launcher
On Tue 26 Jun 2012 12:28, Navanshu Mahor mahor1...@gmail.com writes: I just want to ask what could be the possibility that is giving the following error while running GTK launcher in debug mode: This is probably more appropriate for the webkit-gtk list: http://lists.webkit.org/mailman/listinfo.cgi/webkit-gtk Andy -- http://wingolog.org/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Tab focus order for plugins
Hi all, ap@ is away until July 18, and I was hoping to get some feedback on this change for the WebCore changes. In a nutshell, we'd like certain plugins in chromium to participate in tab focus. My understanding from a recent thread in whatwghttp://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-June/036460.html is that which controls participate in the tab focus cycle is up to the UA. This change plumbs this decision out of WebCore to allow the WebKit embedder to decide whether or not to allow a plugin to participate in tab order on a per-plugin basis. Are there any thoughts or objections to this patch? By default, nothing changes. However certain plugins can choose to participate in the tab focus order, if they support it. Thanks, Fady ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Tab focus order for plugins
Oops, lost the link in the email: https://bugs.webkit.org/show_bug.cgi?id=88958 On Tue, Jun 26, 2012 at 1:26 PM, Fady Samuel fsam...@chromium.org wrote: Hi all, ap@ is away until July 18, and I was hoping to get some feedback on this change for the WebCore changes. In a nutshell, we'd like certain plugins in chromium to participate in tab focus. My understanding from a recent thread in whatwghttp://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-June/036460.html is that which controls participate in the tab focus cycle is up to the UA. This change plumbs this decision out of WebCore to allow the WebKit embedder to decide whether or not to allow a plugin to participate in tab order on a per-plugin basis. Are there any thoughts or objections to this patch? By default, nothing changes. However certain plugins can choose to participate in the tab focus order, if they support it. Thanks, Fady ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Tab focus order for plugins
Hi Fady, I went ahead and reviewed this. - Anders On Jun 26, 2012, at 10:28 AM, Fady Samuel fsam...@chromium.org wrote: Oops, lost the link in the email: https://bugs.webkit.org/show_bug.cgi?id=88958 On Tue, Jun 26, 2012 at 1:26 PM, Fady Samuel fsam...@chromium.org wrote: Hi all, ap@ is away until July 18, and I was hoping to get some feedback on this change for the WebCore changes. In a nutshell, we'd like certain plugins in chromium to participate in tab focus. My understanding from a recent thread in whatwg is that which controls participate in the tab focus cycle is up to the UA. This change plumbs this decision out of WebCore to allow the WebKit embedder to decide whether or not to allow a plugin to participate in tab order on a per-plugin basis. Are there any thoughts or objections to this patch? By default, nothing changes. However certain plugins can choose to participate in the tab focus order, if they support it. Thanks, Fady ___ 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] Notifications for Blob serialization/deserialization
On Tue, Jun 26, 2012 at 10:19 AM, Greg Billock gbill...@google.com wrote: I've been working with Michael Nordman on a problem related to Blob serialization. Currently, if we serialize a Blob, there's no notification to the BlobRegistry, so the serialized Blob will be garbage collected at an indeterminate time if the context in which it was created is closed. This lifetime scoping is spelled out clearly for Blob URLs created using the URL API. I see nothing in the spec imposing the same lifetime scoping on Blobs themselves, so I think it is an implementation flaw. To correctly handle this serialization case, however, the BlobRegistry needs to know when serialization and deserialization operations happen for Blob objects. I've created a patch that adds that logic and plumbs it through to the Chromium API. Webkit patch: https://bugs.webkit.org/show_bug.cgi?id=89921 The corresponding Chromium-side patch is here: http://codereview.chromium.org/10662024/ The strategy I used is to create a new internal URL and use that for serialization: KURL cloneURL = BlobURL::createInternalURL(); blobRegistry().didSerializeBlob(cloneURL, blob-url()); m_writer.writeBlob(cloneURL.string(), blob-type(), blob-size()); m_blobURLs.append(cloneURL.string()); Then upon deserialization, there's a corresponding didDeserializeBlob call. There are a couple alternatives I considered. One is to not instrument the SerializedScriptValue this way, but require callers to use the blobURLs() accessor and do the right thing then. I'm more in favor of inserting this logic directly into serialization, since it removes an implementation gotcha and I think this more closely follows the spec. The blobURLs() accessor was put in as a stop-gap to let us detect Blobs-in-SSVs and fail early when the full plumbing was missing. Don't read too much into its presence. (In practical terms, its current use could be replaced by a does this SSV contain a Blob? flag, but at the time exposing the list seemed like it might be useful.) Since the primary interaction with the BlobRegistry is via URL, I maintained that as well. The other is to use BlobData directly here. Michael is planning on doing some maintenance work to the ID system used internally anyway, and that may end up being the right path to take in that case. The open-ended implication of this change is that throwing away serialized values is now not acceptable -- they need to be checked for blob refs and then have some to-be-written code invoked to trigger the deref of the BlobData. We don't know where all that may be happening, currently, so it's still something of a science project. Please coordinate with ericu@ (I'm sure you're already in contact) who is looking at how to enable Blob support for IndexedDB. It's going to be one of the more exciting cases, which includes SSV data flowing across process boundaries (in the Chromium port), storage to disk, and deletion operations occurring in processes that do not have script contexts available. We already have a SerializedScriptValue object we could interrogate upon destruction, but the whole point is that the wire format created there could show up anywhere, so we need to either restrict that ability and maintain object-level control, or trust callers of the serialized wire string accessor to handle them correctly. Neither is particularly exciting. Any better ideas? -Greg ___ 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] [PATCH] Errors from build-webkit --debug --minimal
Perhaps someone should set up a random bot that will select uniformly at random from the set of *all* supported configurations. If a configuration is known to be unsupported, or is found to be so buggy that it is untenable, the configuration should be removed from the documentation. After all, the point of having all these build switches is so that the user (me) can customize the build. If the switches aren't tested, then they don't work; and if they don't work, there's no point in having them. If I just want to build the core of WebKit2 (omitting optional components where possible), what *is* the recommended approach? Obviously --minimal is a bad idea right now. Also, should I continue passing --debug? It seemed like some of the errors went away without --debug. -Arthur On Mon, Jun 25, 2012 at 12:56 PM, Eric Seidel e...@webkit.org wrote: If someone wanted to set up a --minimal bot, I'm sure that would be welcome. We used to have a --qt --minimal bot at some point. http://trac.webkit.org/wiki/BuildBot On Mon, 25 Jun 2012 12:03:12 -0700, Arthur O'Dwyer art...@push.am wrote: I'm trying to build WebKit by the simplest possible method. I checked out the SVN tree and did cd WebKit ; Tools/Scripts/build-webkit --debug --minimal. This produced compiler errors! I tried the same thing a while ago, and submitted patches to fix some of the issues, but what i was told is that there aren't really any bots building with --minimal, so it's not guaranteed to build. Last i remember, after you fix those issues you mention you're probably gonna come up against trickier ones in --web-audio, --geolocation, --netscape-plugin-api and --fullscreen-api [...] ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [PATCH] Errors from build-webkit --debug --minimal
This is the wrong mailing list to discuss this kind of issue. On this list we discuss contributions to the WebKit project and collaborate on WebKit development. If you want to build WebKit and do not intend to contribute patches, you can ask questions on the webkit-help mailing list as described here http://www.webkit.org/contact.html, or elsewhere. As far as configurations go, despite having some configuration options in the build scripts for convenience of the people working on the project, the contributors to the WebKit project do not intend to support arbitrary combinations of configuration options for WebKit users, even though I’m sure that would be handy. Generally we have a configuration for each port that is tested, and don’t spend our time on the additional work that would be needed to support the other combinations of options and keep them working. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [PATCH] Errors from build-webkit --debug --minimal
On Tue, Jun 26, 2012 at 12:05 PM, Darin Adler da...@apple.com wrote: This is the wrong mailing list to discuss this kind of issue. On this list we discuss contributions to the WebKit project and collaborate on WebKit development. If you want to build WebKit and do not intend to contribute patches, you can ask questions on the webkit-help mailing list as described here http://www.webkit.org/contact.html, or elsewhere. If I could build WebKit, I wouldn't need to contribute patches. ;) See my original post in this thread for an example of a patch that I was forced to contribute. However, I'll go away now. -Arthur ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Notifications for Blob serialization/deserialization
I think revamping our Blob handling is one of the projects that I should be working on next. What we have now is proving to be too difficult to work with in a variety of ways. The more i look at this particular difficulty with sending blobs within serialized values (within chromium), the more convinced i am that we should switch to identifying the 'data underlying a blob' rather than the 'blob object instance'. Currently our 'ids' identify a WebCore::Blob instance. The trouble with putting ids on blob object instances is that they dont cross process boundaries, so we end up either trying to create the id in advance of the instance in some other process, or relying on the originating instance still being around when the new instance in the other process gets coined (based on the originals ids). We have to juggle 2 ids instead of one and conceptually its just a mess. What I'm thinking about is changes along these lines... * WebCore::Blobs have an 'id' that refers to the 'data'. At ctor and dtor time, they increment/decrement a refcount, via ipcs, on the underlying 'data' in the main browser. A clone or copy of that WebCore::Blob instance anywhere in the system will carry that same 'id' and do that same refcounting of the underlying data. * When a IPC message containing a serialized blob (the id value) is in transit, extra refs are applied to the underlying blob data. There are several cases where we need to consider a blob as 'in transit'. Being referred to in an WebCore::SSV is one place. Being referred to in a content::SSV is another. As those objects come and go, they should inc/dec any blobs they refer to accordingly. A content::SSV has to distinguish between running in the main browser process and a child process to do that properly. * A challenging case is when sending SSVs containing blobs from the browser process to a child (renderer|worker) process. After a message is put on the wire going that direction, its not safe to deref the blob data until the receiving side has picked it up and added a ref of its own. I think we'll need ACKS for messages flowing in that direction so the browser-side knows when its safe to drop the extra in transit ref. * Its easier going the other way, from child to browser, since if the child has a ref when the 'id' is put on the wire, that ref cant possibly be removed prior to that msg reaching the browser. Not sure how much of this disccusion affects webkit's native blob handling really? This whole chromium multi-process problem doesn't exist there. I think we can put high level abstractions in webcore that we then fork at that high level... and the forked chromium impl deals with the complexities in our multi-process case w/o impatcing webcore's native single process impl. Another source of difficulty stems from how the ThreadableBlobRegistry posts all operations to the 'main' webkit thread. That's not going to work very well with how we handle IDB operations entirely from the 'context' thread even if its a background worker context. Message sent on behalf of blobs take a longer slower route to reach our main browser process than those sent on behalf of IDB, so an IDB message that contains a blob id may reach the main browser prior to the blob messages that create that blob reach the main browser. I think we have to avoid going thru the 'main' webkit thread in the chromium port for the blob handling messages to avoid odd races. On Tue, Jun 26, 2012 at 11:03 AM, Joshua Bell jsb...@chromium.org wrote: On Tue, Jun 26, 2012 at 10:19 AM, Greg Billock gbill...@google.comwrote: I've been working with Michael Nordman on a problem related to Blob serialization. Currently, if we serialize a Blob, there's no notification to the BlobRegistry, so the serialized Blob will be garbage collected at an indeterminate time if the context in which it was created is closed. This lifetime scoping is spelled out clearly for Blob URLs created using the URL API. I see nothing in the spec imposing the same lifetime scoping on Blobs themselves, so I think it is an implementation flaw. To correctly handle this serialization case, however, the BlobRegistry needs to know when serialization and deserialization operations happen for Blob objects. I've created a patch that adds that logic and plumbs it through to the Chromium API. Webkit patch: https://bugs.webkit.org/show_bug.cgi?id=89921 The corresponding Chromium-side patch is here: http://codereview.chromium.org/10662024/ The strategy I used is to create a new internal URL and use that for serialization: KURL cloneURL = BlobURL::createInternalURL(); blobRegistry().didSerializeBlob(cloneURL, blob-url()); m_writer.writeBlob(cloneURL.string(), blob-type(), blob-size()); m_blobURLs.append(cloneURL.string()); Then upon deserialization, there's a corresponding didDeserializeBlob call. There are a couple alternatives I considered. One is to not instrument the SerializedScriptValue this way, but require
[webkit-dev] Timeline for upgrading to new hardware
Hello all, We are planning to upgrade our Buildbot infrastructure to new hardware on Thursday, June 28th. We would like to start this process around 5pm. During the transition, build.webkit.org will be down. If all goes smoothly, there would be a downtime of around half an hour. This could be longer if we discover problems. We are hoping the bot admins can be available to help bring the slaves back online if they do not automatically connect. I'd like to know if this timeline will work for all of you. If not, please let me know asap so we can plan a more convenient time. Thanks, Lucas Bill ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] New Feature Flag Proposal: TIME_INPUT_FIELDS
Hi WebKit! I would like to notify adding new feature flag ENABLE_TIME_INPUT_FIELDS. This flag will enable multiple fields input UI for input type time. Looking is as same as input type number (including spin button), but each time component, hour, minute, second, millisecond, period(AM/PM), is fixed and handles keyboard input as overwriting rather than inserting, like Mac OSX's DateTime control. This feature will be enable for desktop version of Chrome (== excluding Android). This flag also introduce following class and functions: * DateTimeFormat class * localizedDecimalSeparator() * localizedTimeFormat() * localizedShortTimeFormat() * DateTimeFIeldElement (for shadow DOM) * DateTimeEditElement (for shadow DOM) Thanks! -yosi ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] New Feature Flag Proposal: TIME_INPUT_FIELDS
Hi WebKit! I would like to notify adding new feature flag ENABLE_TIME_INPUT_FIELDS. This flag will enable multiple fields input UI for input type time. Looking is as same as input type number (including spin button), but each time component, hour, minute, second, millisecond, period(AM/PM), is fixed and handles keyboard input as overwriting rather than inserting, like Mac OSX's DateTime control. This feature will be enable for desktop version of Chrome (== excluding Android). This flag also introduce following class and functions: * DateTimeFormat class * localizedDecimalSeparator() * localizedTimeFormat() * localizedShortTimeFormat() * DateTimeFIeldElement (for shadow DOM) * DateTimeEditElement (for shadow DOM) Thanks! ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Lots of email to this list is showing up too small for me to read
Some of the email to the WebKit lists is now showing up in 10 point size rather than the default size for my mail reader. I’m having a hard time reading the small text and I have to do various tricks to make these mails readable. It seems to mostly be from people at Google. Did you guys change something recently in a mail program you are all using? -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Lots of email to this list is showing up too small for me to read
On Tue, Jun 26, 2012 at 10:05 PM, Darin Adler da...@apple.com wrote: Some of the email to the WebKit lists is now showing up in 10 point size rather than the default size for my mail reader. I’m having a hard time reading the small text and I have to do various tricks to make these mails readable. It seems to mostly be from people at Google. Did you guys change something recently in a mail program you are all using? Interesting. I'm not experiencing that problem on my Gmail. Maybe Gmail changed its behavior to specify the font size (I think almost everyone from Google uses Gmail to replay emails)? Could you send me a copy (markup and possibly a screenshot) of emails you see this problem and ones you don't see this problem? - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New Feature Flag Proposal: TIME_INPUT_FIELDS
On Tue, Jun 26, 2012 at 9:20 PM, Yosi Inoue yo...@chromium.org wrote: Hi WebKit! I would like to notify adding new feature flag ENABLE_TIME_INPUT_FIELDS. This flag will enable multiple fields input UI for input type time. Looking is as same as input type number (including spin button), but each time component, hour, minute, second, millisecond, period(AM/PM), is fixed and handles keyboard input as overwriting rather than inserting, like Mac OSX's DateTime control. This feature will be enable for desktop version of Chrome (== excluding Android). Android already enables time (and date) inputs, and defers to the platform's input mechanisms. Will the appearances of the controls be consolidated? Peter This flag also introduce following class and functions: * DateTimeFormat class * localizedDecimalSeparator() * localizedTimeFormat() * localizedShortTimeFormat() * DateTimeFIeldElement (for shadow DOM) * DateTimeEditElement (for shadow DOM) Thanks! ___ 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] Lots of email to this list is showing up too small for me to read
On Jun 26, 2012, at 10:12 PM, Ryosuke Niwa wrote: Could you send me a copy (markup and possibly a screenshot) of emails you see this problem and ones you don't see this problem? Yes. I did that. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Lots of email to this list is showing up too small for me to read
It appears that the ones with the said problem has font size=2 applied to the entire message. An interesting thing is that this font element appears to be ignored on Gmail. It's unclear to me what the underlying problem is but I'll file a bug internally at Google and see what happens. Thanks for letting us know of this problem. On Tue, Jun 26, 2012 at 10:19 PM, Darin Adler da...@apple.com wrote: On Jun 26, 2012, at 10:12 PM, Ryosuke Niwa wrote: Could you send me a copy (markup and possibly a screenshot) of emails you see this problem and ones you don't see this problem? Sure. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New Feature Flag Proposal: TIME_INPUT_FIELDS
Will the appearances of the controls be consolidated? No. In other words, to use different appearances among platforms, I introduced this flag in addition to ENABLE_INPUT_TYPE_TIME. ENABLE_TIME_INPUT_FIELDS is child flag of ENABLE_INPUT_TYPE_TIME. When ENABLE_INPUT_TYPE_TIME w/o TIME_INPUT_FIELDS, input type time uses single text field and doesn't change current behavior. -yosi On Wed, Jun 27, 2012 at 2:19 PM, Peter Beverloo pe...@chromium.org wrote: On Tue, Jun 26, 2012 at 9:20 PM, Yosi Inoue yo...@chromium.org wrote: Hi WebKit! I would like to notify adding new feature flag ENABLE_TIME_INPUT_FIELDS. This flag will enable multiple fields input UI for input type time. Looking is as same as input type number (including spin button), but each time component, hour, minute, second, millisecond, period(AM/PM), is fixed and handles keyboard input as overwriting rather than inserting, like Mac OSX's DateTime control. This feature will be enable for desktop version of Chrome (== excluding Android). Android already enables time (and date) inputs, and defers to the platform's input mechanisms. Will the appearances of the controls be consolidated? Peter This flag also introduce following class and functions: * DateTimeFormat class * localizedDecimalSeparator() * localizedTimeFormat() * localizedShortTimeFormat() * DateTimeFIeldElement (for shadow DOM) * DateTimeEditElement (for shadow DOM) Thanks! ___ 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
[webkit-dev] New feature flag: ENABLE_CSS_POSITION_STICKY
We intend to work on an experimental implementation of a new CSS position type that we're calling sticky, as proposed here: http://lists.w3.org/Archives/Public/www-style/2012Jun/0627.html This will be done behind a ENABLE_CSS_POSITION_STICKY flag. This flag will be used to hide the implementation from the web (but not necessarily compile out all the relevant code). The bug is: https://bugs.webkit.org/show_bug.cgi?id=90046 Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
