Re: [webkit-dev] Should we consider switching to git over svn?
On 10/9/07 8:29 AM, Oliver Hunt [EMAIL PROTECTED] wrote: Unfortunately, git is still not as user friendly as svn, and has a relatively steep learning curve (largely due to it using some similar commands to svn for completely different purposes :-/ ) My understanding is that tool support for git is much worse, too - e.g., I didn't see any in Xcode. Admittedly, I haven't done much branch merging (for WebKit or otherwise), but from my point of view, svn is not broken, and thus doesn't need to be fixed :) - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Windows WebKit/Safari incompatibilities have been resolved
I'm trying to make a debug build of WebKit work with Safari beta, but it still crashes on launch. Event Viewer says: Dependent Assembly Microsoft.VC80.DebugCRT could not be found. Last error was The referenced assembly is not installed on your system. However, I do see the debug libraries in C:\Windows\WinSxS (as well as in \Manifests and \Policies). I have already tried repairing .NET and running vcredist_x86 (not that they have anything to do with debug libraries AFAICT). I have also re-installed VC Express using a repair option in its installer. Does this configuration work for anyone? Any other voodoo I can try to make it work? - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Windows WebKit/Safari incompatibilities have been resolved
on 31.10.2007 15:23, Alexey Proskuryakov at [EMAIL PROTECTED] wrote: I'm trying to make a debug build of WebKit work with Safari beta, but it still crashes on launch. Turns out the problem was caused by my incorrect configuration - I didn't install SP1 on VC++ Express. - WBR, Alexey Proskuryakov. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Keeping track of supported specs on wiki
on 10.11.2007 01:55, Rob Burns at [EMAIL PROTECTED] wrote: However, I think its better to show all of the standards whether targeted by Apple or not. There are a lot of specifications out there - how would you decide whether one is suitable for inclusion on this page? E.g., should we waste bandwidth explicitly stating that we are not interested in RFC 3251 support? However, I assume other contributors are free to bring standard supports to WebKit. I know of two such projects myself where contributors are working to bring standards support to WebKit not currently targeted by Apple. If they are working on such support, they can edit the page to mention that - it's a wiki. - WBR, Alexey Proskuryakov. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Layout test failure
on 12.12.2007 22:22, Rui Jiang at [EMAIL PROTECTED] wrote: Pardon me for this newbie problem. I just followed instructions on webkit.org, got a clean svn checkout yesterday, did a build and all successful. However, when I ran the layout test, they all failed. I could run safari, it works mostly when browsing webpages, however, whenever I type in the address bar, it crashes. This was a bug introduced yesterday and already fixed - please update again! As for layout test failures - I think that on Windows, this is expected behavior, because of how tests are set up internally by Apple. Maybe I'm missing something though. - WBR, Alexey Proskuryakov. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Changes to keyboard event handling
In the latest WebKit nightlies, we have changed keyboard event handling to match Internet Explorer much more closely. This has fixed some compatibility bugs, although it remains to be seen whether significant problems with WebKit-specific content will be uncovered. It is entirely possible that we will need to undo some or all of these changes at some point. Conceptually, the changes all have a single root cause. We now treat keydown as an event corresponding to a physical key press which hasn't been translated with a keyboard layout yet - and keypress corresponds to a character being typed. Of course, we continue to support textInput as a more modern text event suitable for international input. Here is a list of changes that were made since Safari 3 release with Mac OS X 10.5 Leopard: - Keydown and keyup events have a zero charCode property. The reason is that charCode is not known before translating a key press. These events have a keyCode property whose value is a Windows virtual key code, and a keyIdentifier property. - Keypresses do not have a keyIdentifier property. The reason is that a character is not necessarily associated with a single physical key press, so it's not possible to identify a key. However note that keypress events still have a keyCode property whose value matches charCode for IE compatibility. - Arrow keys no longer result in keypress events. These do not correspond to characters, and are now processed in keydown default event handler. - Tabbing between controls no longer results in keypress and textInput events. Just the same, changing focus is not a character event. - Backspace and delete also do not generate keypress events any more. - Modifier keys now generate keydown/keyup events with proper keyCode and keyIdentifier properties. - Preventing default handling of a keydown event now prevents keypress from being sent. - Preventing default handling of a keydown event no longer prevents access key handling. - Pressing Space highlights a button, and releasing it dispatches a click event. Previously, click was dispatched from keypress handler, and the button was highlighted momentarily. However, Enter key press on a button still dispatches click from a keypress event default handler to match IE - Enter and Return keys can not be differentiated by character code any more. Previously, the code for Enter was erroneously reported as 3. If needed, these characters can still be differentiated via keyLocation property of a keydown event. - Mac only: Emacs editing shortcuts (Ctrl+A, Ctrl+E etc) are now executed from keydown default handler. Behavior of application-defined shortcuts (Cmd+A etc) is still being looked into, and may also change soon. One consequence from the above changes is that Mac key codes (such as 63232 for up arrow) are never exposed via DOM any more. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Re: [webkit-changes] [29033] trunk
on 30.12.2007 06:33, [EMAIL PROTECTED] at [EMAIL PROTECTED] wrote: http://bugs.webkit.org/show_bug.cgi?id=16669 autotools update and fixes ... +* dom/Document.cpp: +* loader/icon/IconDatabase.h: +* page/DOMWindow.cpp: +* page/InspectorController.cpp: +* page/Settings.cpp: +* storage/Database.h: + - Remove ENABLE(DATABASE) inclusion guard. Let the includer add the guard instead. Is this something needed for autotools? I think our approach was to have guards in headers, and there are many more examples of this, e.g. with SVG and XSLT. - WBR, Alexey Proskuryakov. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] ACCEPT request header in XMLHttpRequest not meaningful
on 03.01.2008 23:06, Max Barel at [EMAIL PROTECTED] wrote: As I know no way to guess xhtml capability from javascript and modify this default header, webkit gets xhtml served as text/html. Does this qualify for a bug report or a feature request or do I miss something? We could probably change the default to match Firefox, but I do not really see the logic behind using the same Accept string for main resource loading and for XHR, given that Firefox itself uses different Accept strings for subresources. As you said, serving as XHTML is your policy. Obviously, the priority of the bug would be higher if it cited technical reasons for this policy, as it would mean that many people could benefit from a fix. Side note: As long as the correct namespace is used, document content is almost OK. Almost because every linefeed between elements created from ajax data is displayed as #cdata-section in the web inspector. Is this a difference from Firefox? This sounds like something worth investigating to me. - WBR, Alexey Proskuryakov. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit not caching properly?
On Mar 14, 2008, at 10:17 AM, Cameron McCormack wrote: I thought I experienced cases where WebKit was re-requesting resources when it should have been caching them, so I made a small test: http://arc.mcc.id.au/temp/2008/cache-test This works as expected for me on Mac OS X 10.5.2 with stock Safari/ WebKit. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] What libxml2 features are needed for WebKit?
On Mar 26, 2008, at 1:28 AM, Leonid Romanov wrote: Yep, you are right about libxslt: XPath is indeed required. I do wonder, however, what all XPathBlahBlahBlah files in WebCore/xml are for? Well, its not like I really need to know the answer to this particular question, just want to get better understanding of WebKit architecture. These are used by XPathEvaluator. It is not practical to use libxslt for it for performance reasons. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] UTF-16 default mappings in WebKit
On Mar 31, 2008, at 3:20 PM, Sergey Groznyh wrote: So my question is, what is the reason for WebKit to treat UTF-16 data as being little-endian by default? This is done for compatibility with other browsers (and thus with actual content existing on the Web). Sounds like you are using native Java support for text decoding. Have you investigated using icu4j? I could turn out to a better match, given that we use ICU in C++, and have quite a few tweaks for Web compatibility in TextCodecICU. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Locale-aware text breaking
On Apr 4, 2008, at 5:07 PM, Sergey Groznyh wrote: I wonder if there's any plans/ideas on implementing the locale-aware text breaking in WebKit? Here in the Java port I've implemented this for line break iterators (so the Java port is able to split e.g. Thai text correctly), but I'd rather adopt the common approach if it does exist (or is planned.) As of ICU 3.6, dictionary-based Thai word boundary detection is supported regardless of locale, so this case works correctly in mainline WebKit, too. In general, language-specific engine features (such as better font selection) are blocked on http://bugs.webkit.org/show_bug.cgi? id=16801 - we do not have a practical way to tell what the language is yet. Did you use :lang in your port, or just some system-wide default? - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Does WebKit support 304 Not Modified for Ajax requests?
On May 10, 2008, at 2:39 AM, Maciej Stachowiak wrote: Anyone know what is going on? We support If-Modified-Since but not If-None-Match when revalidating. The best place to file the bug would be http://bugreport.apple.com/ because it is actually an issue in CFNetwork, the underlying network library that WebKit uses (at least on the Mac and Windows ports). Scott has filed https://bugs.webkit.org/show_bug.cgi?id=18972, and we are trying to find out what is going on (I couldn't reproduce the issue so far). - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Preventing menus on Windows
On May 22, 2008, at 5:38 PM, Johan Lund wrote: How can I prevent e.g. the File menu to popup on Alt-F in Safari in Windows? We do not allow web pages to suppress handling of system keys events like this, matching Internet Explorer. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit memory management?
On Jun 4, 2008, at 9:58 AM, Paul Pedriana wrote: Thanks for the response. I'm sorry, and perhaps I misunderstand, but I believe your statement about inline operator new is incorrect. Unless I misunderstand you, what you say is not supported by any existing compiler nor is it supported by the C++ language standard. In summary, the 'inline' keyword does not negate or obviate the One Definition Rule. You can demonstrate the problem with the code below. Feel free to correct any misunderstanding that I may have of your explanation. You are right that the presence of a declaration or inlining do not affect the behavior of overridden global operator new, other than via possible implementation-specific quirks (because compilers are not required to detect ODF violations). However, I am not aware of any platforms where an overridden operator new would have effect across a DLL boundary (note that the C++ standard doesn't talk about dynamic linking at all). So, this is only an issue if you link WebCore to your application statically, or specifically export operator new from your DLL. There is no need to do the latter, and the former sounds like a violation of LGPL to me. If your platform does not support dynamic linking, or you cannot use it for some other reason, you may want to investigate the legal feasibility of using LGPL-licensed code in your projects before pursuing technical solutions. Thus you could use WC_NEW(WebCore/page) to flag the memory as belonging to that subsystem. This is invaluable in identifying memory, producing subsystem metrics, optimizing memory coherence, and deducing memory leaks (though other means also help find leaks). So far, we've been quite happy using platform tools for memory debugging. Personally, I do not think that explicitly tagging memory in this way would be cost-effective, although this is certainly not out of the question. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] keyboard event handling - set in stone yet?
On Jun 17, 2008, at 3:51 PM, Johan Lund wrote: I was wondering what the behavior is like now and if it has been finalized yet? Here is the article: https://lists.webkit.org/pipermail/webkit-dev/2007-December/ 002992.html There were no substantial changes to keyboard event handling model since then. We do have some outstanding bugs that need to be fixed (most notably, we need to make it so that Web pages cannot block all Safari shortcuts on the Mac), but overall, the current behavior proved to be adequate for Web compatibility. In the long term, some changes may or may not be needed to better align with DOM3 Events specification. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JSImmediate.h 64 bit compatibility problem?
On Jun 30, 2008, at 1:22 PM, Paul Pedriana wrote: I see the following code, which works for 32 bit but not 64 bit. Is there another file or function somewhere that's for 64 bit? JSImmediates are 32 bit, even on 64 bit platforms. What is the problem that you are seeing? - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Faster run-webkit-tests?
On Jul 12, 2008, at 1:07 AM, Stephanie Lewis wrote: Something else you can look at is running run-webkit-tests with the -- threaded flag. It runs with the test multiple javascript threads. You can run that and see if it highlights any other issues. The last time I ran with that flag (a while ago) there were a large number of failures. I'm running tests with --threaded all the time, and that mostly works fine for me. There is a test or two that cause out of memory conditions, which sometimes makes secondary threads crash (as we only check for such at a few places where they are likely). I would be very interested in your results with ToT. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] API in webkit to convert Unicode -- HTML named entities?
On Jul 21, 2008, at 10:15 PM, Dan Wood wrote: I've been looking for an API to convert from a unicode character to its named HTML entity (like euro; or auml;) -- if it exists -- and vice-versa. Not a specific API, but if you make WebKit parse the text (e.g. with loadHTMLString:baseURL:), it will be available via DOM methods as Unicode characters. I do not think that there is any way to make WebKit do the conversion to named entities - but maybe numeric entities like #x0441; would meet your requirements? I'm not quite sure what you need to achieve though. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [webkit-changes] [35474] trunk/JavaScriptCore
On Jul 31, 2008, at 10:38 AM, [EMAIL PROTECTED] wrote: Try to clean up our usage of USE(MULTIPLE_THREADS) vs. USE(PTHREADS) a little. There is indeed some confusion between MULTIPLE_THREADS and PTHREADS in JSC now. One of the reasons is that some of the threading code can be used in WebCore even if JSC is not threaded, and vice versa. The former macro enables JSC multithreading, while the latter in not as clear cut. It looks like JSC assumes that if MULTIPLE_THREADS is defined, then pthreads will always be available I'm not sure that's always the case for gtk, certainly not for Windows. We should eventually go back and fix wtf/Threading.h to cover all these cases some day. Yes, JSC currently assumes that pthreads is available for MULTIPLE_THREADS. It is not at all obvious to me that this is a wrong assumption - we'd need a compatibility layer for platforms that don't have native pthreads anyway, so why not use existing pthreads implementations for these platforms? We do that on Windows, for example. Let's discuss this before declaring it wrong at least. Modified: trunk/JavaScriptCore/kjs/collector.h (35473 = 35474) --- trunk/JavaScriptCore/kjs/collector.h 2008-07-31 06:14:13 UTC (rev 35473) +++ trunk/JavaScriptCore/kjs/collector.h 2008-07-31 06:38:54 UTC (rev 35474) @@ -28,9 +28,6 @@ #include wtf/Noncopyable.h #include wtf/OwnPtr.h #include wtf/Threading.h -#if USE(MULTIPLE_THREADS) -#include pthread.h -#endif This change in particular seems wrong to me - the file uses pthread_key_t under #if USE(MULTIPLE_THREADS), but pthread.h is only included in Threading.h under #if USE(PTHREADS). - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [webkit-changes] [35474] trunk/JavaScriptCore
On Jul 31, 2008, at 12:58 PM, Eric Seidel wrote: I think it's wrong for JSC to assume pthreads. Gtk seems to have its own threading system. Windows does too. It's unclear to me (aside from the comment below) why it needs them long term. Any custom solution that we may come up with will be quite heavyweight - it is not correct to assume that WTF::Mutex can just call through to a mutex (or critical section) provided by the platform, for example, as the semantics differ a lot. We'd basically need to take pthreads implementations for all platforms and import those into WTF, possibly changing the coding style. Yes, I'm exaggerating, but not too much :) Now, what's the benefit of importing pthreads into WTF compared to using it as an external library? - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [webkit-changes] [35474] trunk/JavaScriptCore
On Jul 31, 2008, at 1:11 PM, Alexey Proskuryakov wrote: We'd basically need to take pthreads implementations for all platforms Or we could take the code from another existing library - e.g., ThreadingWin uses code from Boost. Again, the benefits are not obvious to me. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [webkit-changes] [35474] trunk/JavaScriptCore
On Jul 31, 2008, at 11:30 PM, Brent Fulgham wrote: Since WebKit has its own threading abstraction layer, I think it is unwise for code outside this layer to make use of the special knowledge that pthreads is in use. Whatever you want to be doing via calls to pthreads primitives should instead be handled using one of the WTF/Thread methods. If no such method exists, it should be added so that proper variants for the specific platforms are used. Well, what I'm saying is that maintaining our own abstraction layer is a large and unnecessary burden. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [webkit-changes] [35474] trunk/JavaScriptCore
On Aug 1, 2008, at 12:49 PM, Paul Pedriana wrote: It would constitute a bit of code duplication if our Windows apps linked both EAThread and pthreads. Instead it would be better if we just made a small inline shim between the pthread interface and EAThread, so any pthreads calls would be just inline redirections to EAThread. Well, I guess that in such case, there is little point in using pthreads API, and you'd be better served with ThreadingEA.cpp? All port authors who spoke prefer (to a different degree) their own WebKit-specific threading implementations to using pthreads. Hard to argue with that, even though I still dislike the idea for the reasons stated earlier. I think I'd like to eventually move Apple's Windows port from ThreadingWin to ThreadingPthreads anyway, but that's a separate topic for discussion. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Anyone tried out of memory
On Aug 19, 2008, at 2:54 PM, Mikael Tennhammar wrote: But have anyone tried this before? Knows anything about it? Or is there a policy how to handle the case where a allocation is failing? Starting with http://trac.webkit.org/changeset/35691 (last week), fastMalloc() aborts on failed allocations, so I guess that this is what the policy is. In a few cases where the caller knows how to handle out of memory conditions (e.g. by raising a JavaScript exception), a version of fastMalloc() that doesn't crash is called. Talking about ports that cannot use fastMalloc go, some work towards making it possible to use custom allocators is tracked by https://bugs.webkit.org/show_bug.cgi?id=20422 . - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Fix for Vector::m_inlineBuffer alignment?
On Sep 4, 2008, at 2:05 AM, Paul Pedriana wrote: I see that JavaScriptCore/wtf/Vector.h has this: // FIXME: Nothing guarantees this buffer is appropriately aligned to hold objects of type T. char m_inlineBuffer[m_inlineBufferSize]; We have a bug for this: https://bugs.webkit.org/show_bug.cgi? id=16925. Also, https://bugs.webkit.org/show_bug.cgi?id=19775. There are several patches and suggestions in these bugs, which wait for someone to submit them as clean patches. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Fix for Vector::m_inlineBuffer alignment?
That's a great list of subtle issues (I can add that atomicity guarantees are different for non-aligned access sometimes) - it would be fantastic if we could amend it with actual data, say SunSpider results and/or DOM performance tests on Intel Mac and/or Windows. If we got an improvement on SunSpider/Mac, we wouldn't have to discuss processors running in non-native endianness modes :-) - WBR, Alexey Proskuryakov On Sep 4, 2008, at 1:24 PM, Paul Pedriana wrote: This is a hardware issue and can vary between different versions. Some hardware of course generates an unhandled exception on unaligned access; some hardware generates an internally handled exception and restarts the access with a different and more expensive pathway or with microcode; some hardware efficiently handles it as it goes and has minimal impact. Sometimes this behavior is different depending on whether the hardware is in big endian vs. little endian mode. A new generation of the same processor family or a version by a different company may act differently than another. Finally, if that memory is accessed by a different means than the CPU (e.g. via DMA or the video bus), then it may require alignment where it doesn't otherwise. What I'm getting at here is that I think we would need to be careful about disabling it for any hardware, including even forgiving hardware like x86. On Sep 4, 2008, at 12:20 PM, Paul Pedriana wrote: I'll make a patch and attach it to https://bugs.webkit.org/show_bug.cgi?id=16925 , if that's OK. That would be great! One thing I'm not sure about is whether we want to enforce alignment on platforms that don't require it - performance testing should answer this. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] keypress not firing when wmode=transparent Flash in focus
on 14.09.2008 06:13, astgtciv at [EMAIL PROTECTED] wrote: Should I submit this to WebKit Bugzilla? Please do. It would be best to file a separate bug for the original issue that you are trying to work arond, as well - it might be a Flash bug, but not necessarily (it's also possible that bugs are present on both sides). - WBR, Alexey Proskuryakov. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Webkit unicode question
On Sep 23, 2008, at 7:47 PM, Sherif wrote: i want to ask, does webkit supports unicode? Yes. Are you interested in some particular aspect of Unicode support? I'm not sure how Python could be related to your question. If not, is it possible to interfere it with python to support unicode? - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Safari and complex script rendering
on 28.09.2008 12:15, Paul Pedriana at [EMAIL PROTECTED] wrote: It seems to me that complex script would have to be supported by something other than WidthIterator::advance (is it?). There are multiple parts for such support indeed, which has to do with different requirements for rendering, editing and DOM APIs. See e.g. iteration support in Position and VisiblePosition. Of course, supported never means absolutely bug-free - no implementation of text rendering, and probably not even any spec works perfectly for all scripts and all use cases. - WBR, Alexey Proskuryakov. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setTimeout as browser speed throttle
Sep 30, 2008, в 6:37 PM, Mike Belshe написал(а): Thanks for the concrete examples, Dave! I tested all 3 of these, and haven't yet found any problems. But I don't have specific URLs. I also looked through the webkit bugs database as much as I could, and could not locate them. One example is https://bugs.webkit.org/show_bug.cgi?id=6998. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setTimeout as browser speed throttle
Sep 30, 2008, в 8:13 PM, Mike Belshe написал(а): Thanks - I did see that bug. Intentionally spinning the CPU vis setTimeout(,0) is not a problem if it is what the application intended. I don't quite agree - even though this may have been the intention, the application developer will not be aware of all the consequences without testing in Safari/Chrome. The site will work perfectly in IE and Firefox, but in WebKit-based browsers, it will eat battery, make the computer too hot to hold on one's knees, and change the pitch of noise coming from it. These are quite practical issues. It may also work faster - but chances are that this delay is not important for user experience, given that the code was deployed and works adequately in other browsers. Otherwise, I certainly agree that having a high resolution timer support is a good idea. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setTimeout as browser speed throttle
Sep 30, 2008, в 9:12 PM, Mike Belshe написал(а): As for keeping the fan off - if we could keep the CPU idle a 3ms minimum timeout loop does that resolve your concern? Maybe, partially. As mentioned in bug 6998, even 10 ms timers incur non-trivial processor usage. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] window.location
on 08.11.2008 07:53, Bin Hu at [EMAIL PROTECTED] wrote: I got some problems with window.location in Safari. A JS function like window.location='someURL' just does not work and Safari will reload the page. Is there any solution for this? Thanks. Similar behavior is found in Opera. Please file a bug at http://bugs.webkit.org. We'll need a test case, because this usually works, so a short description is not sufficient for investigation. - WBR, Alexey Proskuryakov. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Is there any way to disable the spellchecking in textfields
Nov 12, 2008, в 5:53 PM, Johan Lund написал(а): Can I control spellchecking on/off from html/css in some way in webkit? https://bugs.webkit.org/show_bug.cgi?id=14552 Add a way to disable spell checking for specific element - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JavaScriptCore: Lookup object by string?
Nov 13, 2008, в 1:22 PM, Daniel Waylonis написал(а): I'm using JavaScriptCore Framework in a Cocoa program. I'm trying to evaluate a function in the JavaScript code via C, but I'm having problems with figuring out how to get a proper reference to that function. You need to evaluate the JavaScript source, then look up the function by name as a global object property: JS_EXPORT JSValueRef JSEvaluateScript(JSContextRef ctx, JSStringRef script, JSObjectRef thisObject, JSStringRef sourceURL, int startingLineNumber, JSValueRef* exception); JSValueRef JSObjectGetProperty(JSContextRef ctx, JSObjectRef object, JSStringRef propertyName, JSValueRef* exception) Here, object will be a result of JSContextGetGlobalObject(), and propertyName will be AddOne. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] how to destroy JSObjescts?
Nov 26, 2008, в 12:23 PM, Iulian написал(а): With JSGarbageCollect() the finalize() function of myStaticObject gets called, but the finalize() function of myDynamicObject doesn't get called. Perhaps the address of myDynamicObject is on the stack when you call JSGarbageCollect()? That would prevent it from being collected, of course. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] copy/paste/keychain support?
Dec 4, 2008, в 12:08 AM, Lev Lvovsky написал(а): While I did previously install some safari enhancers, I'm fairly positive that they've been completely uninstalled - is there any way to check? You can check the contents of the following directories: ~/Library/InputManagers /Library/InputManagers ~/Library/Application Support/SIMBL/Plugins/ /Library/Application Support/SIMBL/Plugins/ ~/Library/Application Enhancers/ /Library/Application Enhancers/ Installed plugins shows nothing out of the ordinary. Plug-ins are different from Safari enhancers, as they work via documented and stable APIs. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] XMLHttpRequest and Workers
Dec 15, 2008, в 9:47 AM, David Levin написал(а): This is how I plan to finish making XMLHttpRequest available for workers http://docs.google.com/Doc?id=dg7mj9sd_6dvthmdqj Let me know if you have any comments. As discussed earlier, this looks good to me. It may make the code more complicated to handle both WorkerContext and Document in some places (like responseXML) It makes the code a bit more fragile to future changes in which code may be added that uses document() which is executed on the Worker. To alleviate this, it makes sense to divide up the functionality into three classes: XMLHttpRequestBase, XMLHttpRequest, and XMLHttpRequestWorker. In general, I expect 90%+ of the functionality to be in XMLHttpRequestBase, but any references to document() will be isolated to XMLHttpRequest. I'm not much of a fan of this idea, because we want to make Worker functionality closer to main thread one in the future, and this would be a step in opposite direction. On the other hand, this division can be undone later if needed, so it all depends on how much forking needs to be introduced in XMLHttpRequest otherwise. As far as fragility is concerned, I think that the right way to avoid it is via extensive test coverage. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] XMLHttpRequest and Workers
Dec 16, 2008, в 7:45 PM, Darin Fisher написал(а): I'm not much of a fan of this idea, because we want to make Worker functionality closer to main thread one in the future, and this would be a step in opposite direction. On the other hand, this division can be undone later if needed, so it all depends on how much forking needs to be introduced in XMLHttpRequest otherwise. Can you elaborate on those future plans? You want to allow the responseXML method of XHR to work in the future? To expose data DOM support to workers? Or, are there other things as well? Yes, I think that this is something developers will naturally expect, and will ask us to implement. Even the original version of the spec said that data DOM had to be supported, although that was quickly removed due to implementor feedback. This is not a specific plan yet. - 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 more buildbots green
Jan 3, 2009, в 10:41 PM, Darin Adler написал(а): http/tests/appcache/offline-access.html — Seems to have timed out once on Mac. It has timed out locally a couple of times for me, too, but never when I was trying to reproduce intentionally. No idea what's going on yet. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] memory leaks seen by leak bot
Jan 21, 2009, в 10:12 AM, Darin Adler написал(а): But there also seem to be a bunch related to worker threads: http://build.webkit.org/results/trunk-mac-intel-debug/5816/DumpRenderTree5-leaks.txt I couldn't quickly figure out how to fix those worker-thread related ones yet. Oliver helped me fix one of the leaks in https://bugs.webkit.org/show_bug.cgi?id=23456 . I don't see the other ones locally on an x86 debug build, although I'm hitting an ugly assertion failure sometimes: run-webkit-tests --leaks -1 fast/workers Thread 3 Crashed: 0 com.apple.JavaScriptCore 0x00582d12 WTF::Mutex::lock() + 80 (ThreadingPthreads.cpp:199) 1 com.apple.JavaScriptCore 0x004d78c6 WTF::LockerWTF::Mutex::Locker(WTF::Mutex) + 38 2 com.apple.JavaScriptCore 0x0057b1ef JSC::Structure::Structure(JSC::JSValuePtr, JSC::TypeInfo const) + 465 3 com.apple.JavaScriptCore 0x00506898 JSC::Structure::create(JSC::JSValuePtr, JSC::TypeInfo const) + 56 (Structure.h:56) 4 com.apple.JavaScriptCore 0x0057cfe8 JSC::Structure::toDictionaryTransition(JSC::Structure*) + 126 (Structure.cpp:484) 5 com.apple.JavaScriptCore 0x004ff835 JSC ::BatchedTransitionOptimizer ::BatchedTransitionOptimizer(JSC::JSObject*) + 81 6 com.apple.JavaScriptCore 0x005288de JSC::Interpreter::execute(JSC::EvalNode*, JSC::ExecState*, JSC::JSObject*, int, JSC::ScopeChainNode*, JSC::JSValuePtr*) + 378 (Interpreter.cpp:979) 7 com.apple.JavaScriptCore 0x005293f1 JSC::Interpreter::callEval(JSC::ExecState*, JSC::RegisterFile*, JSC::Register*, int, int, JSC::JSValuePtr) + 407 (Interpreter.cpp:541) 8 com.apple.JavaScriptCore 0x0052956b JSC::Interpreter::cti_op_call_eval(void*, ...) + 337 (Interpreter.cpp: 5742) 9 com.apple.JavaScriptCore 0x0051e914 jscGeneratedNativeCode + 0 (Interpreter.cpp:4166) 10 com.apple.JavaScriptCore 0x0053fdc8 JSC::JIT::execute(void*, JSC::RegisterFile*, JSC::ExecState*, JSC::JSGlobalData*, JSC::JSValuePtr*) + 56 (JIT.h:359) 11 com.apple.JavaScriptCore 0x00527706 JSC::Interpreter::execute(JSC::ProgramNode*, JSC::ExecState*, JSC::ScopeChainNode*, JSC::JSObject*, JSC::JSValuePtr*) + 740 (Interpreter.cpp:868) 12 com.apple.JavaScriptCore 0x004aa11e JSC::evaluate(JSC::ExecState*, JSC::ScopeChain, JSC::SourceCode const, JSC::JSValuePtr) + 472 (Completion.cpp:67) 13 com.apple.WebCore 0x03c3ba05 WebCore::WorkerScriptController::evaluate(WebCore::ScriptSourceCode const) + 265 (WorkerScriptController.cpp:89) 14 com.apple.WebCore 0x03c3c33b WebCore::WorkerThread::workerThread() + 259 (WorkerThread.cpp:109) 15 com.apple.WebCore 0x03c3c4bf WebCore::WorkerThread::workerThreadStart(void*) + 17 (WorkerThread.cpp: 99) 16 com.apple.JavaScriptCore 0x00582886 __ZN3WTFL16threadEntryPointEPv + 112 (Threading.cpp:58) 17 libSystem.B.dylib 0x90d2c095 _pthread_start + 321 18 libSystem.B.dylib 0x90d2bf52 thread_start + 34 - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Bug ID:23744
19.02.2009, в 16:23, taruchhaya singh написал(а): 1) /*comment*/ is a valid CSS statement, which is escaped/ignored while executing the code. So shouldn't the same approach be followed in this case and @charset should be considered/honored. You need to test Firefox and Internet Explorer to find the answer to this. 2) I also found another issue in this bug,i.e. in Link Tag. I don't see any code in your e-mail, but anyway, please file a new bug with steps to reproduce if you've found a separate issue. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] multithread webcore and KJS
20.02.2009, в 5:11, whzeng написал(а): I want to start a thread for each WebView, and then let KJS run in multiple threads environment, feasible? WebCore and WebKit can only be used from the main thread. But we support Web Workers API for running scripts on multiple threads now, see http://whatwg.org/ww; and JavaScriptCore API can be used from multiple threads simultaneously. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] if-modified-since not working with https
27.02.2009, в 8:00, Scott Schmitz написал(а): I have an ajax application which has been optimized to use if- modified-since to minimize the data traffic. It used to work fine on Safari, but now I am seeing that it works when I make the request using http but does not when I make the request using https. I am wondering what the problem is? I had been seeing a problem earlier with large data sets being returned not being cached - like anything above 100k would not cache. I believe this was fixed, but am wondering if there's something special about https caching? Are there size limits? Perhaps you never cache? This sounds related to https://bugs.webkit.org/show_bug.cgi? id=24159. In any case, please file a bug via http://bugreport.apple.com for Apple engineers working on network back-end to investigate this problem. It is not part of open source WebKit, so discussing it is not really on topic here. You said that this used to work - it would help a _lot_ to know when exactly it broke. Here's the AJAX request: https://www.scottschmitz.com/subscription/AJAX/GetList.php?userID=37databaseName=Contactformat=Contact It would be great if your bug report linked to a complete test case (including JavaScript code that makes the request). - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit does not refresh cached resource
18.03.2009, в 9:11, halaiwa написал(а): What is the correct way to work with the WebKit cache, how to force it to load the resource from server based on Last-Modified header? It should work in accordance with http://www.ietf.org/rfc/ rfc2616.txt. Does the response specify an age for it to be considered stale? Do you see the same problems with Safari? CFNetwork DLL is not redistributable, so using it with other clients is not supported. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Pushing data to plugin
20.03.2009, в 17:23, Jack Wootton написал(а): Does anyone have any experience with these functions? I am trying to use them but am getting link errors. Which library to i need to link against to use them? A plug-in gets pointers to these functions in an NPNetscapeFuncs structure passed to its initialization routine. So, there is no library to link against. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Pushing data to plugin
20.03.2009, в 18:15, Jack Wootton написал(а):
I'm unsure about how I can access the Browser functions.
You can see how this works in one of our example plug-ins. E.g., form
TestNetscapePlugin:
NPNetscapeFuncs *browser;
// Mach-o entry points
extern C {
NPError NP_Initialize(NPNetscapeFuncs *browserFuncs);
NPError NP_GetEntryPoints(NPPluginFuncs *pluginFuncs);
void NP_Shutdown(void);
}
// Mach-o entry points
NPError NP_Initialize(NPNetscapeFuncs *browserFuncs)
{
browser = browserFuncs;
return NPERR_NO_ERROR;
}
- WBR, Alexey Proskuryakov
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] make webkit-1.1.3
On 27.03.2009, at 12:57, Zoltan Horvath wrote: you have to update your system's ICU to 4.0. (http://site.icu-project.org/download) Is this a requirement only for the Gtk port? On other platforms, ICU as old as 3.2 is still used, although with some differences in behavior. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Creating custom DOM events
On 08.04.2009, at 3:10, Ross Lillie wrote:
element onMyCustomEvent=function() {}
The public interfaces in WebKit don't appear to provide the
functionality I
need. The private interfaces in WebCore appear that they might. Am
I on
the right track?
WebCore internal methods are subject to frequent changes, so calling
them directly is not recommended.
You can avoid the need to do add the custom attribute by not using it,
and registering the event handler via element.addEventListener() in
your JavaScript code.
- WBR, Alexey Proskuryakov
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Allowing webkit clients to extend XHR security policy
On 09.04.2009, at 11:38, Aaron Boodman wrote: Chromium extensions run in the same scheme (chrome-extension://), but they do not run in the same origin. They all have unique origins of the form chrome-extension://extension-id/. Security origin is scheme + host + port. OK, I didn't know that the scheme was hierarchical (seems obvious in hindsight). So, we don't have any major problems with this feature! I don't mind doing it on FrameLoaderClient. Forgive the noob question, but I'm newish to webkit... How should this be plumbed? I don't have a definitive answer (which is why I originally suggested modeling the solution after FrameLoader::registerURLSchemeAsLocal() and avoiding callbacks). Clearly, doing it on FrameLoaderClient is no different from doing it via a non-static call on any other client class, like the potential ScriptOriginClient - either ScriptOrigin will need to keep a pointer to client class, or all callers will need to pass it with each call. At least the preflight stuff for AC logically belongs to DocumentThreadableLoader - we need to move it there to reasonably implement redirects for cross-origin requests. The rest (which I think is just canLoadLocalResources checks for Dashboard) isn't relevant to this discussion, because these checks do not access static data. But how will DocumentThreadableLoader know what policy to apply? Some things are allowed to be loaded across origins (iframes) without AC, and some things aren't (XHR). Maybe I am misunderstanding and DocumentThreadableLoader is only used for XHR? Or maybe there is some context that will be available? I'm sure I'm just misunderstanding here, I'm just curious what you had in mind more than anything. ThreadableLoader is used for different things indeed, but it is is already configurable (e.g. whether to do content sniffing, or to use loading callbacks), and could take more configuration options. I see it as a bottleneck for DOM-initiated loading - that is, everything that can be initiated from a worker, as opposed to markup. The distinction is admittedly rather vague - e.g. if we ever allow XML DOM and XSLT in workers, XSL stylesheets will need to be loaded through this interface, too (but those are also known to be a potential future application of cross-origin access control). Regardless of how it plays out in the future, I think that moving access control implementation to loader thread/process is a clear win. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [webkit-changes] [42428] trunk
On 13.04.2009, at 3:10, wei...@apple.com wrote: Move more attributes out of JSDOMWindowBase by partially generating them. We need to do the same to JSWorkerContextBase (which I think will let us eliminate it quickly). +attribute MessagePortConstructor MessagePort; + #if ENABLE_CHANNEL_MESSAGING -attribute MessagePortConstructor MessagePort; +attribute [JSCCustomGetter] MessageChannelConstructor MessageChannel; // Usable with the new operator #endif Why this change? It is mentioned in ChangeLog, but with no explanation. MessagePort is defined in section 7.3 of HTML5, which is not at all surprisingly called Channel messaging. I suggest undoing this change, unless there is a significant reason for it. (WebCore::JSDOMWindow::xMLHttpRequest): :-( - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Allowing webkit clients to extend XHR security policy
Yes, making changes as discussed in bugzilla, plus removing registerURLSchemeAsLocal would be a fine direction. - WBR, Alexey Proskuryakov On 12.04.2009, at 22:58, Aaron Boodman wrote: It sounds to me like our current patch is the best fit because it fits our needs, will work with Chromium's out-of-process workers, plus it allows us to remove FrameLoader::registerURLSchemeAsLocal() as Alexey requested. It has the downside that the client will get called on multiple threads, but this will automatically be fixed when the DocumentThreadableLoader refactor work is done. Can I get a yay or nay (from Alexey or other interested people) on moving forward with that patch? We're happy to do the work to remove registerURLSchemeAsLocal() while we're in there. Alternatively, can I get an idea for a different approach that would be accepted? Thanks, - a On Fri, Apr 10, 2009 at 10:23 AM, Aaron Boodman a...@chromium.org wrote: On Thu, Apr 9, 2009 at 9:50 PM, David Levin le...@google.com wrote: On Thu, Apr 9, 2009 at 9:03 PM, Alexey Proskuryakov a...@webkit.org wrote: On 09.04.2009, at 22:38, Aaron Boodman wrote: The local scheme feature is actually more powerful than just XHR If you only need extensions to do XHR, why not just make them use cross-origin XHR? That way, the extension won't even need to declare the origins it's going to access - all checks will be server-side, as with normal cross-origin XHR. I think the idea is that a user could install an extension and the user could trust the extension to do the cross-origin xhr (without the server for the x-origin doing anything special). For example, I used to have the book burro FF extension (http://www.bookburro.org/) which displayed prices for books from several book stores when you visit another online book store. Exactly. Sorry for not making this clear in the original mail. - a ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [webkit-changes] [42428] trunk
On 13.04.2009, at 11:05, Sam Weinig wrote: Why this change? It is mentioned in ChangeLog, but with no explanation. MessagePort is defined in section 7.3 of HTML5, which is not at all surprisingly called Channel messaging. I suggest undoing this change, unless there is a significant reason for it. My mistake. We don't seem to compile with CHANNEL_MESSAGING enabled, but I thought we supported MessagePorts, so I was confused. Currently, the only way to create a MessagePort is via a MessageChannel. That is fully implemented in ToT, however the MessagePort API may need to change to better suit worker needs, so we don't want to expose it yet. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorker design doc
Hi Drew, Thanks for the detailed proposal, it's great to have one. Prior to diving into threading details, I'd like to clarify a background assumption that doesn't seem to be mentioned in the proposal. How does a SharedWorker relate to the browsing context that created it? Specifically, we probably don't want a SharedWorker to be a top browsing context, because that would be an easy way to subvert same origin cookie policy. And since loading in WebCore can only happen when there is a Frame, what will happen to a SharedWorker whose original frame goes away? 18.04.2009, в 8:55, Drew Wilson написал(а): Any feedback would be appreciated, especially for some of the cross- threading and worker lifecycle issues. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [webkit-changes] [42699] trunk/WebCore
21.04.2009, в 9:59, gga...@apple.com написал(а): Renamed *InlineEventListener* = *AttributeEventListener*, and isInline = isAttribute. -EventListener* Node::getInlineEventListener(const AtomicString eventType) const +EventListener* Node::getAttributeEventListener(const AtomicString eventType) const I think that per our coding style guidelines, this function should be named attributeEventListener(): 6. Precede setters with the word set. Use bare words for getters. Setter and getter names should match the names of the variables being set/gotten. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorker design doc
22.04.2009, в 2:31, Drew Wilson написал(а): David's take is that long term we'll need to change the loader code so it is not dependent on a specific frame - his upcoming refactoring may facilitate this, but there will still be a significant amount of work to achieve this in WebKit. Over the short term, he suggested that we might be able to suspend the parent frame, such that it still exists for the purposes of allowing associated workers to perform network loads, but it itself no longer has an open window and its active DOM objects are shutdown. When the last child worker exits, the parent frame can be completely discarded. A problem with this approach is communicating to the user - e.g. asking for HTTP authentication credentials. Without an open window, it won't be possible to display a sheet, and if we were to display a dialog window instead, the user wouldn't know which site needs the credentials. We do need to make loading work for frameless documents (e.g. to support XSLT document() function), but in other cases I'm aware of, we can rely on a parent window being visible. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Where should design descussions take place? (WAS: Bug 25436: Refactor appCache for use in multi-process browsers)
02.05.2009, в 0:15, Jeremy Orlow написал(а): We were actually talking about design discussions like this one. The original context was my email on how to make localStorage multi- process aware. Where we discuss designs doesn't matter to me, but I would like to reach a consensus on the subject. I think that the criterion is quite simple - if there is a bug, or enhancement request, or a patch to be reviewed, then the discussion goes to Bugzilla. E.g., the discussion of appcache changes suggested by Michael should definitely take place in https://bugs.webkit.org/show_bug.cgi?id=25436 . Let's talk about how resource loading is implemented in Chromium and whether this can serve as a model for other projects potentially using WebKit in multi-process configuration is neither of the above. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] link-following feature for our new webkit browser.
04.05.2009, в 17:19, Jan Kolkmeier написал(а): 2. Go to link $i: window.location = document.links[i].href; This isn't nice at all, because it doesn't work with ajax-ish web pages. As already asked on IRC, could please clarify what you mean by doesn't work? In particular, the following works as I would expect it to: a href=javascript:alert(0)link/a scriptwindow.location = document.links[0].href;/script - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] MessagePorts and garbage collection
06.05.2009, в 21:38, Drew Wilson написал(а): It looks like the JSC collection code relies on JSLock to lock the heap - I'm guessing that I'll need to explicitly grab the JSLock whenever I'm manipulating the linkage between the two ports, is that correct? Or is there a different/better way to handle situations like this? The JavaScriptCore implementation of MessagePorts only supports document contexts (i.e., it only works on main thread). As mentioned earlier, the first thing needed to implement MessagePorts in workers is a design of how they can be passed around without breaking GC. It is likely that taking a lock whenever atomicity is desired will cause deadlocks. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setting a size limit for Application Cache
06.05.2009, в 23:09, Michael Nordman написал(а): There is no means for the system to distinguish between these two cases. There is no API to indicate which use is which. The first use case (just speeding things up) sounds like something that should be handled by a normal HTTP cache, as defined in RFC 2616. Is it inadequate? If it is, maybe it should be improved instead of making an additional entirely different caching mechanism? - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Memory leaks
13.05.2009, в 23:32, Husam Senussi написал(а): I ran the test cases in the above directory and in test cases for JSON code and end up with reported leaks in the same ares, I thought it might b something I have introduces but I can't find anything related to my code changes in the stack trace dump. Yes, I'm seeing a number of similar leaks in ToT. I'm going to investigate tomorrow, unless someone beats me to it. Thanks! - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Memory leaks
13.05.2009, в 23:51, Alexey Proskuryakov написал(а): I ran the test cases in the above directory and in test cases for JSON code and end up with reported leaks in the same ares, I thought it might b something I have introduces but I can't find anything related to my code changes in the stack trace dump. Yes, I'm seeing a number of similar leaks in ToT. I'm going to investigate tomorrow, unless someone beats me to it. https://bugs.webkit.org/show_bug.cgi?id=25784. Unfortunately, some of the leaks seem to be in closed source frameworks beneath WebKit. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] using DumpRenderTree
On 19.05.2009, at 14:23, Subramanya wrote: When I check using breakpoints I get an error is obtained in the function static void stopJavaScriptsThreads(void) in the line free(pthread). This looks like a bug in DumpRenderTree to me. Could you please file it at http://bugs.webkit.org? It may well be that the tests weren't run with the --threaded option on Windows in a long time. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [webkit-changes] [43878] trunk/WebCore
+// FIXME: POST documents are always Reloads, but their subresources should still be Revalidate. I think the comment should say should still be Verify, unless actually reloading the page. +// If we bring the CachePolicy.h and ResourceRequest cache policy enums in sync with each other and +// remember Revalidate in ResourceRequests, we can remove this POST check and return either Reload +// or Revalidate if the DocumentLoader was requested with either. +const ResourceRequest request(documentLoader()-request()); +if (request.cachePolicy() == ReloadIgnoringCacheData ! equalIgnoringCase(request.httpMethod(), post)) +return CachePolicyRevalidate; + Will this work correctly for reloading a POSTed page? I think that it probably will, as the code below returns CachePolicyRevalidate anyway, but given the comment, I'm a bit confused. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
22.05.2009, в 3:20, Drew Wilson написал(а): SharedWorkers have explicit access to the ApplicationCache APIs, while dedicated Workers merely inherit the ApplicationCache from their parent window. What is the use case for this? It doesn't seem useful to me - to invoke update explicitly, one normally needs to have UI anyway, at which point it's much easier to call update() directly from a page. A tangentially related question: what will happen to a SharedWorker whose cache got updated? Will the repository use a new source for new instances, while the old ones will continue to run? Looks like there is a significant potential for mistakes here, as scripts won't normally expect several instances of the same SharedWorker to be active. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
01.06.2009, в 22:37, Drew Wilson написал(а): 1) Since SharedWorkers aren't explicitly tied to a specific Document, it doesn't make sense to have them possibly get loaded from an out-of-date version of the app cache. If you have two separate documents running from different caches, it's weird (and indeterminate) if the version of the cache used to load the SharedWorker script is dependent on which one happens to call new SharedWorker() first. I don't see how exposing DOMApplicationCache methods to workers can help this - a worker will only be able to call DOMApplicationCache.update() after it has started, which is too late. Besides, won't the document using an old version of cache break if a newer SharedWorker is suddenly returned to it? The main idea of appcache is that all application resources are versioned, so if we see SharedWorkers as part of application, they should use the same cache version. And if they are independent entities with a stable API, using an out of date version for a while cannot hurt. As for what happens to a SharedWorker whose cache was updated? My presumption is that all future resource loads would use that cache. At that point, the SharedWorker has a few different things it could do: Reload all of its scripts again using importScripts(). This implies that its script loading is idempotent, but that's not too hard to do. Send messages to all of its client documents letting it know that it is shutting down, then invoke close() to shut itself down. The client documents can re-create the SharedWorker the next time they want one. This is inherently race-y, though, since you can't easily coordinate the shutdown of the worker with instantiations of new ones. Do nothing at all All of these options seem quite dangerous - it may be difficult for JS authors to write applications that won't break at update time. A document can reload itself after updating, but SharedWorkers do not have a way to reload themselves. As you mentioned, they can reload imported scripts (but the main script will remain the same, which would be inconsistent). Or they can shut down and ask a document to re- create themselves - at which point, we can as well say that the document can update the cache. Interaction of SharedWorkers and appcache, explicit or not, sounds like a major issue to me. It can significantly affect the design (or even make SharedWorkers not worth being added, if no acceptable solution is found). - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
02.06.2009, в 1:29, Michael Nordman написал(а): What is the use case for this? It doesn't seem useful to me - to invoke update explicitly, one normally needs to have UI anyway, at which point it's much easier to call update() directly from a page. The use case are workers that can be considered faceless applications. They are versioned independently of user interfaces that make use of them thru a stable message based API. Is it really possible for a SharedWorker to be versioned independently from UI? When a document calls a SharedWorker constructor, the worker script is loaded from the document's appcache (because all subresource loading goes through appcache, of course). So, its source always matches the UI version. Even if there is a newer version of appcache already loaded, the document's one will be used for loading subresources. When a worker's script is referenced from several appcaches, this becomes somewhat trickier. As Andrew correctly mentioned, the version used will depend on which application was the first to construct the SharedWorker. But how is it a problem if we require SharedWorkers to implement a stable messaging API? Given that SharedWorkers are versioned together with UI, and that loading a new main resource in UI always invokes update process, I'm not sure if there are any use cases that require workers to call update() on their own. This is quite similar to how faceless helpers in large native application suites work - I don't think that they ever check for updates, it's only done at application startup. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
02.06.2009, в 0:19, Drew Wilson написал(а): My design doc just reflects the current spec - I don't really intend to be the defender of said spec. As I said previously, I think this is the wrong venue for us to describe issues with the spec - we should do it on the whatwg list to include other stakeholders. Did my response to Michael Nordman's message make the nature of objections more clear? I'd be happy to start that conversation on the whatwg list, but to be honest I don't think I'm quite understanding what your objections to the current spec are. Would you mind kicking off that discussion with whatwg, outlining your concerns? I think that there is value in discussing this among WebKit developers, as we can talk about how the design corresponds to low level implementation details. This is always important, but it would create a communication barrier on other venues. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
02.06.2009, в 21:10, Drew Wilson написал(а): If worker global scope is actually a SharedWorkerGlobalScope object (i.e. the worker is a shared worker), and there are any relevant application caches that are identified by a manifest URL with the same origin as url and that have url as one of their entries, not excluding entries marked as foreign, then associate the worker global scope with themost appropriate application cache of those that match. I'm not at all certain what most appropriate application cache means, but I *think* it means most up-to-date cache, not cache associated with the constructing document. I think that's the point that this discussion hinges upon. Michael, do you know what that phrase means? There's a vague definition of most appropriate in the spec: Multiple application caches in different application cache groups can contain the same resource, e.g. if the manifests all reference that resource. If the user agent is to select an application cache from a list of relevant application caches that contain a resource, that the user agent must use the application cache that the user most likely wants to see the resource from, taking into account the following: • which application cache was most recently updated, • which application cache was being used to display the resource from which the user decided to look at the new resource, and • which application cache the user prefers. In current implementation, most appropriate is just random, but the second test is what I think applies to SharedWorkers most closely. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
From Andrew's design document, I don't see how my description was inaccurate: --- Currently, all worker XHR requests are proxied to the parent page and executed on the main thread. This approach currently works for dedicated workers because there is a 1:1 mapping between dedicated workers and active pages, and the worker is shutdown when the page closes. For SharedWorkers (and for dedicated workers once we introduce nested workers) this is no longer the case - the worker can outlive the parent page. To address this, we will use the DocumentSet for the worker. Worker XHR requests will still be proxied to the main thread. This task will request the DocumentSet from the repository, and select a document from that set to use to satisfy the request. If the DocumentSet is empty, then it means that the worker is shutting down, so the XHR should return a failure response. --- From my reading of this, it appears that shared workers will use FrameLoader of the opener page, or some other page in the DocumentSet, and won't get their own loaders (that would be a feature of persistent workers, which we aren't even discussing yet). This speaks specifically about XHR, but I assumed that the same holds true for other network requests. - WBR, Alexey Proskuryakov 02.06.2009, в 21:18, Michael Nordman написал(а): When a document calls a SharedWorker constructor, the worker script is loaded from the document's appcache (because all subresource loading goes through appcache, of course). If I understand correctly, that is not what the spec currently says. Dedicated workers load as you describe, but not shared workers. The algorithm to determine what resource to load for a shared worker is the same as the algorithm used to determine what resource to load for a window.open(urlToPageWithoutAManifestAttributre) call. Personally, I think we should defer adding support for the appcache scriptable API to workers for the time being. But do support the resource loading / cache selection as currently specified. This would allow shared workers can be versioned independently (despite not having a good reload worker after an update story). These are shared workers. That implies a degree of separation from the pages that are sharing them. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
02.06.2009, в 21:59, Michael Nordman написал(а): Per the spec, shared workers are a distinct browsing context. In appcache terms, they have a distinct appcache host. We have to come up with a design that accomplishes that. OK, I was getting a feeling that we talked about different things. Andrew, do you agree that a different design is needed, or is this something we should push into the spec instead? - WBR, Alexey Proskuryakov ___ 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
02.07.2009, в 9:44, Eric Seidel написал(а): DETAILED DESCRIPTION OF THE CHANGES GOES HERE. (OOPS!) SEE: http://webkit.org/coding/contributing.html FOR MORE INFORMATION Tests: fast/foo.html * foo.cpp: Added. |n most cases, detailed description of changes would better be per- file or per-function, not in a blob above the list of changes. - WBR, Alexey Proskuryakov ___ 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
02.07.2009, в 18:05, Adam Roben написал(а): - I prefer having Bug N: before the actual bug description so I don't have to parse the URL myself for the bug number. It also acts as a visual marker when I read the ChangeLog entry. ... Here's an example entry that follows the format that I (and I think Dave) like: +2009-04-20 Adam Roben aro...@apple.com + +Change MemoryStream::createInstance to return a COMPtr + +Part of Bug 25294: All WebKit/win classes should return COMPtrs from +their static constructor members +https://bugs.webkit.org/show_bug.cgi?id=25294 FWIW, I rarely need to know the bug number alone - I need its URL to click or to copy/paste. On the other hand, the suggested format makes it so that one needs to skip over Part of Bug 25294: just to read the bug description, which is not an improvement. - I like putting angle brackets around the URL to set it off visually from other text. Typing those brackets is more work. It's also more difficult to copy/ paste the URL (you could just copy the whole line and paste it into Safari address bar when there were no garbage symbols around the URL) - I generally move the Reviewed by line after the bug number/ description/URL. When you're reading a ChangeLog entry/commit message (especially an older one), it's generally much more interesting which bug is being fixed rather than knowing who reviewed it. (Also, putting the bug description first makes git's one-line description of each commit much more useful than either having a list of dates and the person who wrote the patch or having a list of patch reviewers.) No strong opinion about this one. It seems natural to have the reviewer mentioned close to contributor (which is what we have now). - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] exposing the value of Accept-Language via window.navigation.acceptLanguage ?
22.07.2009, в 16:41, Jungshik Shin (신정식, 申政湜) написал(а): Some web apps/widgets/browser extensions can also benefit from knowing the ordered list of languages in Accept-Language. I should note that Safari only sends one language. The reasons for this are: - protecting users' privacy, as a list of spoken languages can help identify a site visitor better than the primary preferred language; - improving Web compatibility, as servers happen to have most weird problems with complicated Accept-Language strings. So, the difference between Accept-Language and navigator.language is very minimal for us. 22.07.2009, в 20:21, Maciej Stachowiak написал(а): * - Kind of off topic, but I found this incredibly frustrating recently when traveling in countries where I did not know the native language. Yes, this kind of auto-detection is quite frustrating, and it becomes even more frustrating when sites say This content is not available in your country. This makes me very skeptical of any proposals that let sites get more information about users without their explicit consent. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] exposing the value of Accept-Language via window.navigation.acceptLanguage ?
22.07.2009, в 22:36, Darin Fisher написал(а): Firefox and Chrome send very similar A-L headers. Given FF's marketshare, I'm surprised you observed compat problems with doing the same. Was that a recent observation? Can you provide more details about the issues you observed? It's not recent, see http://lists.macosforge.org/pipermail/webkit-dev/2005-June/000217.html . There is also some discussion in https://bugs.webkit.org/show_bug.cgi?id=3510 , not sure if any of it is still relevant. I do not have a reference handy, but IIRC, sending quality values was breaking some widely deployed intranet webmail system. It should be noted that normally people only have one value (or one family of values: en and en-US for example) on the A-L list, and that they have to configure their browser to advertise other languages. I think that addresses the privacy concerns, assuming suitable wording in the configuration panel. Safari takes the languages from system configuration. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Building WinCairo, WebCore has lots of SilenceAssertionsOnly undefined or not a member of JSC
28.07.2009, в 4:05, Thomas Brodt написал(а): I've seen that there is 46441/442 that deals with SilenceAssertionsOnly, but prefixing JSC:: doesn't work. Currently the winCairo doesn't build with 46462 because of these undeclared identifier SilenceAssertionsOnly or SilenceAssertionsOnly not a member of JSC if prefixed with JSC::, both release and debug. Just a hickup today? On some machines, a clean build was needed for CoreGraphics Windows port, because obsolete JSC headers were picked from an old location. Maybe it's the same with Cairo port? - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Building WinCairo, WebCore has lots of SilenceAssertionsOnly undefined or not a member of JSC
28.07.2009, в 8:51, Thomas Brodt написал(а): Should I cleanup more than --clean? I just wipe the WebKitBuild directory when I need to rebuild. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] NeverNullT
28.07.2009, в 15:25, Eric Seidel написал(а): It just occurred to me that we have a lot of places in WebKit were we ASSERT(foo) (where foo is some passed in Foo* pointer which should never be NULL). I like to use references instead of pointers that can never be null. This doesn't always work well with existing WebKit code though. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Application caching in the browser?
15.08.2009, в 20:15, Audrey Lee написал(а): I'm looking for demos/tutorials/discussions which would teach me how to do this. Wrong list, please use webkit-h...@lists.webkit.org. The specification for application cache is part of HTML5, http://www.whatwg.org/specs/web-apps/current-work/#offline . - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Runtime setting for incomplete features
18.09.2009, в 12:24, Jeremy Orlow написал(а): I'm not sure if we've hit any compatibility issues with this yet, but it seems quite plausible that someone would compare window.localStorage (or sessionStorage or database) to undefined and, since it's null (vs. undefined), their script would assume it's available. Note that they can also do 'localStorage in window', which we can't easily prevent from returning true. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Skipping Flakey Tests
28.09.2009, в 17:00, Maciej Stachowiak написал(а): p.s. I now have two skipping flakey tests changes up for review: https://bugs.webkit.org/show_bug.cgi?id=29322 If Brady and Alexey are ok with disabling this test, then I'm fine with it. I like Alexey's suggestion to have a separate flaky tests list that the commit queue script can ignore, without preventing them from being run at all. I'm investigating this one now, it looks like we have a refcounting issue with some new code in CString/CStringBuffer. I'd prefer to keep this test enabled (and it's a good thing that it's been causing lots of pain, that's what keeps regression count low). - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Runtime setting for incomplete features
06.10.2009, в 0:39, Maciej Stachowiak написал(а): For now, there are no SocketStreamHandle implementation. so even enabling WebSockets in Settings, it is the almost same that the feature is not available.. As far as I'm concerned, that's ok for testing, even though we would not want to ship that way. If the state is so bad that we don't even want people testing, then the feature should be compiled out entirely. In my opinion, anyway. Without a SocketStreamHandle implementation, there is probably nothing people can test - as there will be no network activity at all. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ThreadIdentifier abstraction is inefficient
29.10.2009, в 13:31, Jens Alfke написал(а): I filed a bug on this: https://bugs.webkit.org/show_bug.cgi?id=30922 My first suggestion is just to typedef ThreadIdentifier to pthread_t (if pthreads are in use) and avoid the need for a mapping altogether. Any reason this wouldn't be a good idea? (If not, I have two other suggestions in the bug report.) For those following along at home, this has been duped to https://bugs.webkit.org/show_bug.cgi?id=25348 , which already has some interesting discussion, and will undoubtedly have more. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Staging WebSocket protocol deployment
While WebSocket API is fairly stable, the discussion of underlying protocol at IETF is far from being done. It could be disruptive to ship our WebSocket implementation in a way that would effectively freeze the protocol. One way to achieve future compatibility is by using a different scheme for WebSocket URLs - e.g. webkit-ws: and webkit-wss: instead of ws: and wss:, respectively. Depending on how protocol standardization goes, we could alias these later, or add a separate standards compliant implementation. I'm going to submit a patch to this effect, but would like to discuss the idea on the list first. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [webkit-changes] [50959] trunk/WebKitTools
I'm not sure if this is a great approach. Previously, people with other default locales exercised code paths that aren't normally taken on U.S. systems, and thus could catch problems affecting shipping products early. It is beneficial that DRT results get more predictable, but tests are most useful when they fail, not when they pass :) - WBR, Alexey Proskuryakov 13.11.2009, в 12:04, kenn...@webkit.org написал(а): Revision 50959 Author kenn...@webkit.org Date 2009-11-13 12:04:24 -0800 (Fri, 13 Nov 2009) Log Message Set the locale to C and not to the current one in use on the system. Reviewed by Simon Hausmann. * DumpRenderTree/qt/DumpRenderTree.cpp: (WebCore::DumpRenderTree::resetToConsistentStateBeforeTesting): Modified Paths trunk/WebKitTools/ChangeLog trunk/WebKitTools/DumpRenderTree/qt/DumpRenderTree.cpp Diff Modified: trunk/WebKitTools/ChangeLog (50958 = 50959) --- trunk/WebKitTools/ChangeLog 2009-11-13 19:56:43 UTC (rev 50958) +++ trunk/WebKitTools/ChangeLog 2009-11-13 20:04:24 UTC (rev 50959) @@ -1,3 +1,12 @@ +2009-11-13 Kenneth Rohde Christiansen kenn...@webkit.org + +Reviewed by Simon Hausmann. + +Set the locale to C and not to the current one in use on the system. + +* DumpRenderTree/qt/DumpRenderTree.cpp: + (WebCore::DumpRenderTree::resetToConsistentStateBeforeTesting): + 2009-11-13 Adam Roben aro...@apple.com Finish replacing worldIDs with world objects Modified: trunk/WebKitTools/DumpRenderTree/qt/DumpRenderTree.cpp (50958 = 50959) --- trunk/WebKitTools/DumpRenderTree/qt/DumpRenderTree.cpp 2009-11-13 19:56:43 UTC (rev 50958) +++ trunk/WebKitTools/DumpRenderTree/qt/DumpRenderTree.cpp 2009-11-13 20:04:24 UTC (rev 50959) @@ -304,8 +304,8 @@ m_page-undoStack()-clear(); -QLocale qlocale; -QLocale::setDefault(qlocale); +QLocale::setDefault(QLocale::c()); +setlocale(LC_ALL, ); } void DumpRenderTree::open(const QUrl aurl) ___ webkit-changes mailing list webkit-chan...@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-changes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [webkit-changes] [50959] trunk/WebKitTools
13.11.2009, в 12:43, Kenneth Christiansen написал(а): FYI this in not just related to Qt, as at least both win and mac have similar code. On the Mac, setlocale is called with locale. I'm not quite sure what that is - man page says it denotes the native environment. If it's resetting locale to original, then it's the behavior I'm lobbying for. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Staging WebSocket protocol deployment
15.11.2009, в 17:18, Yuzo Fujishima написал: Reason 1: It connotes that the feature is experimental. That means there will be less developers seriously use that feature. Without serious use, we'll have less serious feedbacks from the real world. If the Web Socket has serious flaws, we should rather know them sooner than later. I'd say only serious uses can help us find the flaws faster. It doesn't seem that wide use is possible before the protocol evolves into something that works with all proxies - or before a heavyweight service forces network administrators to update their proxies for compatibility with the existing protocol. Frankly, I think that the former is more likely. The only case that is likely to work on Internet reliably right now is running over SSL, which negates some of the protocol's strengths - it will no longer be as efficient as it's meant to be. In order to enable port sharing, this also requires one to serve documents over https, which is an additional cost. Reason 2: What should other browser vendors do? Should they use chrome-ws, firefox-ws, ie-ws, opera-ws, ..., etc? I believe at least developers will not happy with that. If the vendors need to reach the consensus on the common experimental name, say prelim-ws, then why not just use ws instead? In practice, this means half a dozen lines of browser detection code - which does not matter when deploying a technology of this magnitude, as already mentioned in this thread. It seems that a common argument against using a name other than ws is that a scheme is just an opaque identifier, so it doesn't matter which name to use, so we can just change the name later, if necessary. I don't think that this is a strong argument - if the name doesn't matter in the long run (which I wouldn't agree with, but anyway), why sweat about what the name is during experimental rollout of the feature? - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] normalizing namespace indenting
16.11.2009, в 19:54, Chris Jerdonek написал(а): Second, do people prefer nested namespace blocks to end with the fully-qualified name (e.g. // namespace JSC::WREC) or just the final name (e.g. // namespace WREC)? I have seen both. I actually prefer no comment after the namespace ending brace. If I have any concerns about namespaces not being properly closed, I won't believe the comment anyway, and will check by double-clicking on the closing brace to select the block. And if I trust that the namespace structure is correct, then it's just visual noise. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Made a debug build of WebKit.Framework. GDB ignores breakpoints?
18.11.2009, в 9:06, Eddy Bruël написал(а): I've checked out the most recent WebKit sources, and made a debug build. I then linked my program against the resulting WebKit.Framework, and used the headers in the corresponding WebKit.Framework/Headers directory Did you try the steps in http://webkit.org/building/debug.html? There is no need to rebuild your application against a local WebKit build. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New requirement for building on Windows coming
On 24.11.2009, at 9:46, Adam Roben wrote: On second thought, even if we soft-link, we'll still have dependencies on the D3D headers... Can we make a local copy of those? - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New requirement for building on Windows coming
On 24.11.2009, at 11:12, Alexey Proskuryakov wrote: Can we make a local copy of those? On a second thought, the license likely doesn't permit that. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] appendChild does not work for elements produced by DOMParser
On 30.11.2009, at 7:20, Alexander Shabanov wrote: I believe that this is because I'm playing with DOMParser in the wrong way. Could you please clarify what is the error here? This is offtopic in webkit-dev mailing list. Please use webkit-help instead. I think that you may get better results if you parse full documents (with html xmlns=..., body and all) with DOMParser. Or just use parseContextualFragment, as Maciej suggested. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] GlobalScript in WebKit
On 30.11.2009, at 14:05, Dmitry Titov wrote: That also pretty much means if we won't have SharedScript, we'll need to explore other opportunities toward efficient sharing of code and data which does not make people to write a multithreaded UI as SharedWorker solution would do. We have practically zero positive response to SharedWorkers being used this way. Granted, this is just one company but the devs here are good and came from variosu other companies so the limited unscientific poll kind of shows the outcome... This makes me wonder if there is any positive experience using SharedWorkers for this elsewhere - or any better use cases for it. At the moment, it seems that technical issues around shared workers's implementation in WebKit haven't all been resolved yet, and that GlobalObject could be a better replacement for the same use case anyway. Dropping one for another is in the spirit of successful experimentation - what do you think? - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposing style guide change regarding braces on conditional arms
On 02.12.2009, at 23:35, Maciej Stachowiak wrote: One possible conservative modification to the rule is that if you have a multi-block if ... else if ... else chain, then if even one body has braces, all should. I think that would tend to reduce rather than increase visual noise, as all the else keywords would line up where right now they look ragged. That would be my preference, too. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] namespace indent
On 03.12.2009, at 14:22, Jens Alfke wrote: This comes up because I have a patch out for review that includes the addition of an HTTPHeaders namespace that just contains a bunch of string constants: I do not think constants for HTTP headers are part of HTTPHeaderMap - maybe it would be better to add them to a new file. That would resolve the issue with style automatically, although I agree with the rationale you provided. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Strings on multiple threads
On 03.12.2009, at 18:13, Jeremy Orlow wrote: Easier said than done in many cases. For DOM Storage and Databases, there are several classes that are used on multiple threads. And several of these classes contain strings (or contain things that contain strings). It seems very difficult to be absolutely sure these strings are only shared in a safe way unless you make a threadsafeCopy every time you access it. Doing so would probably be negligible performance wise for all the cases I'm looking at, so maybe that's the right answer, but these issues are very subtle. And that's what concerns me most. We should aim to gradually redesign these classes to only use message passing, and generally cleaning up what happens on which thread. It's indeed very difficult to work with strings in this code, but I don't think that's the only problem that arises from using objects on multiple threads there, and it's not necessarily one to tackle in isolation. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebSocket threading design
On 08.12.2009, at 23:44, Darin Fisher wrote: Sounds right to me since it mirrors the solution used to enable XHR from workers. Sounds good to me, too. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] strcmp result checking
As current style rules say that tests for zero/non-zero should all be done without equality comparisons. However, this rule can cause significant readability problems if blindly applied to strcmp: if (!strcmp(string, foobar)) naturally reads as does not equal. I think that this strcmp should be an exception to this rule. Current WebCore uses both forms, with the one I propose being slightly more common. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [webkit-changes] [52980] trunk/LayoutTests
08.01.2010, в 02:22, e...@webkit.org написал(а): * platform/mac/Skipped: Add http/tests/uri/escaped-entity.html to Skipped list since it affects later tests. I think that having this particular test enabled is much more important than having the patch it was affecting landed. Also, looks like this didn't even help, see http://trac.webkit.org/changeset/52990. * platform/mac/svg/W3C-SVG-1.1/filters-conv-01-f-expected.txt: Check in correct results. This should have included pixel results. 08.01.2010, в 06:22, o...@webkit.org написал(а): * platform/mac-snowleopard/Skipped: platform/mac/editing/input/devanagari-ligature.html skipped. Same for this test. How will we notice regressions in text input support if we disable tests? - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
