Re: [webkit-dev] Constant readonly
Hi Darin,
I understand.
thanks for your help.
Mario
On lundi 22 novembre 2010 17:23:18 Darin Adler wrote:
On Nov 22, 2010, at 2:41 AM, Mario Bensi wrote:
I tested if the constant in idl was readonly, like that :
var node = document.getElementById('console');
alert(node.ELEMENT_NODE);
node.ELEMENT_NODE = 666;
alert(node.ELEMENT_NODE);
And it's strange, I can change ELEMENT_NODE value.
I know it's stupid to do this but is it the correct behaviour ?
The property ELEMENT_NODE is read-only on the prototype for nodes. But
there’s no rule against creating a property of the same name on an individual
node. That is what your code does.
If you try:
Node.ELEMENT_NODE = 666;
You’ll see that you can’t change the value on the prototype for nodes.
-- Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Constant readonly
Hi,
I tested if the constant in idl was readonly, like that :
var node = document.getElementById('console');
alert(node.ELEMENT_NODE);
node.ELEMENT_NODE = 666;
alert(node.ELEMENT_NODE);
And it's strange, I can change ELEMENT_NODE value.
I know it's stupid to do this but is it the correct behaviour ?
Regards,
Mario
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] PLATFORM_STRATEGIES
Hi all, In revision 61429, you have introduced PLATFORM_STRATEGIES and you define WTF_USE_PLATFORM_STRATEGIES. It should be ENABLE_PLATFORM_STRATEGIES, no ? Best Regards Mario ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] LayoutTests new-window-opener
Hello, Just an question on this expected : LayoutTests/fast/dom/Window/new-window- opener-expected.txt In test you have this text : On success, you will see a series of PASS messages, followed by TEST COMPLETE. But in expected you have : Toolbar FAIL newWin.toolbar.visible should be true. Was false. PASS newWin.toolbar.visible is false FAIL newWin.toolbar.visible should be true. Was false. PASS newWin.toolbar.visible is false Statusbar FAIL newWin.statusbar.visible should be true. Was false. PASS newWin.statusbar.visible is false FAIL newWin.statusbar.visible should be true. Was false. PASS newWin.statusbar.visible is false Locationbar FAIL newWin.locationbar.visible should be true. Was false. PASS newWin.locationbar.visible is false FAIL newWin.locationbar.visible should be true. Was false. PASS newWin.locationbar.visible is false PASS window.successfullyParsed is true Normaly here I should see only PASS messages and it's not the case. Is it an error or the message is not correct ? Regards Mario Bensi ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] layoutTest animations
Ok, I have create a patch and a bug to attach it, it's here : https://bugs.webkit.org/show_bug.cgi?id=33081 Regards, Mario Le jeudi 31 décembre 2009 00:05:36, Maciej Stachowiak a écrit : On Dec 30, 2009, at 4:27 AM, Mario Bensi wrote: Hello, In LayoutTests/animations/ I can find some test using webkit css/ animation 3D like : LayoutTests/animations/state-at-end-event-transform.html In script run-webkit-tests you remove animations/3d if 3D is not activated but 3d directory not exist in animation. if i disable 3D on webkit, I mean I can have some errors on this tests. It's an error ? or the tests don't use 3D ? I think any tests that depend on 3D animation support should go in animations/3d. If you find any that are in the wrong place, please post a patch to move them. Thanks! - Maciej -- Mario Bensi Join OWB team on freenode IRC, channel #owb Web-enabler for CE devices www.pleyo.com Follow us on twitter : twitter.com/pleyo tel : +339 70 447 544 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] layoutTest animations
Hello, In LayoutTests/animations/ I can find some test using webkit css/animation 3D like : LayoutTests/animations/state-at-end-event-transform.html In script run-webkit-tests you remove animations/3d if 3D is not activated but 3d directory not exist in animation. if i disable 3D on webkit, I mean I can have some errors on this tests. It's an error ? or the tests don't use 3D ? Best Regards Mario Bensi ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] display:none
Hello, I have a question on css propertie display:none. If I try to load this example : html body div style=visibility: hidden; display: none; object type=test/test id=test/object /div /body /html On WebKit the createPlugin is never called and we can't access to script part of my plugin, the plugin are not instantiated. If I try the same page on Firefox it works, my plugin are correctly instanciated but not diplayed, like I want. After read http://www.w3.org/TR/CSS21/visuren.html#display-prop for me the plugin must be instantiated, but no space will be reserved in the layout for it, and no box will be created. is a bug in webkit ? Or I misunderstood something in specification ? Best Regards, -- Mario Bensi Join OWB team on freenode IRC, channel #owb Web-enabler for CE devices www.pleyo.com Follow us on twitter : twitter.com/pleyo tel : +339 70 447 544 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] display:none
yes, it's the same problem. Are you an idea to fix this or a pointer to help me ? Mario Le lundi 30 novembre 2009 19:56:41, Darin Adler a écrit : You have sent your mail to the wrong mailing list. The right one is webkit-help. See this page for details: http://webkit.org/contact.html After read http://www.w3.org/TR/CSS21/visuren.html#display-prop for me the plugin must be instantiated What you describe seems to be a bug where HTML5 describes something different from what WebKit does and other browsers. I found a bug report https://bugs.webkit.org/show_bug.cgi?id=27775 that seems to match what you are saying. -- Darin -- Mario Bensi Join OWB team on freenode IRC, channel #owb Web-enabler for CE devices www.pleyo.com Follow us on twitter : twitter.com/pleyo tel : +339 70 447 544 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposal for a new way to handle porting #ifdefs
The goal of Origyn Web Browser Abstraction Layer (OWBAL) is to clarify what is platform dependant and what is not. In BAL directory you find some modules which split sources per family of feature: Database: all files needed for HTML5 Database and Storage. Events: all events definitions (input events) Filesystem: methods to access the filesystem Geolocation: methods to implement the html5 geolocation ImageDecoder: Interface of ImageDecoder and all implementation (GIF, JPEG, PNG, BMP, ICO) Media: Implementation of backend for HTML5 video/audio tag Network: Implementation of network resource Types: Base Type used by WebCore Facilities: misceleanous facilities implementation Fonts: Font engine implementation Graphics: Graphic primitive implementation (drawline, ...) Internationalization: I18N implementation Memory: memory management implementation SVG: SVG (graphic part, the parser is in WebCore) implementation Timer: timer implementation Widgets: widget implementation Each Module, when needed, splits WebCore and WTF source for the compilation. All files in BAL have the prefix BC for BAL Concretization and for the suffix the implementation name ( SDL, Gtk, Qt... ). This is done to avoid confusion between files in the BAL and WebCore. For example if you have a file ScrollView.cpp in WebCore, in BAL for SDL implementation it will be : BCScrollViewSDL.cpp This way any filename self documents its target implementation. We have a 2 others directories used for the BALification process: * Base: where stand definition of type and all configuration ( Platform.h, ... ). This makes a single place of information. *cmake: all definitions needed by cmake (our build mechanism) such as library check, header include, definitions by option. you can find this description here : http://www.sand- labs.org/owb/wiki/OwbalDescription Mario Le Tuesday 05 May 2009 17:19:33 Maciej Stachowiak, vous avez écrit : On May 4, 2009, at 5:21 AM, Mario Bensi wrote: We pursued the same goal for a couple of years. Since our porting targets are various middleware CE platforms, we had to identify and adapt WebKit needs at a better grained level than platform. In order to do this we collected all dependencies in a Browser Abstraction Layer (BAL directory). The configuration is handled by a Base directory (definition of types, platform specifications) and we use CMake to define platform specificities (and it's a great cross- platform tool). Sure the BAL model has still improvements ahead of it, but it has the merit of existing, being widely tester on a quite wide range of targets, configurations and libraries. My understanding is that BAL injects a platform abstration layer under the platform abstraction layer that is the WebCore/platform directory. Also, I gather that BAL tries to do more things via runtime indirection and subclasses with virtual methods instead of WebCore's compile-time approach. To me, those aspects sound like they may not be good fits for our goals. But I would be glad to hear more details about BAL, and how it would compare to my proposal. Regards, Maciej Regards Mario Le Friday 01 May 2009 01:12:54 Maciej Stachowiak, vous avez écrit : I think our set of porting macros has become somewhat confused. Originally, our idea was that a port represents primarily adaptation to a particular platform. However, over time it has become clear that most of what is decided by a port is not platform adaptation, but rather policy decisions. For example, ports decide to have different features enabled, or to use different sets of system functionality on the same underlying OS. In addition, I think the catchall top-level PLATFORM create confusion, because it is not totally clear if they are policy decisions, platform adaptation decisions, or what. Third, it seems wrong that the policy choices of every port are represented as a bunch of ifdef tomfoolery inside a single Platform.h file. And fourth, many ports often run on the same OS, but with a different set of choices - for example on Mac OS X it is possible to build the Mac, Chromium, Gtk, Qt and Wx ports (at least). Therefore, I propose that we change as follows: 1) Strictly separate platform adaptation (mandatory to run on a given OS, compiler, or CPU at all) from policy choices (what features to enable, what optional libraries to use). 2) Phase out PLATFORM macros completely - each use should be converted to a policy choice, or a platform adaptation decision. 3) Instead of ports being defined by a top-level PLATFORM macro, I propose that each port should have its own header file to define policy decisions. For example, I'd propose that the system Mac OS X WebKit should use PortCocoa.h, and the WebKit used by Safari for Windows should use PortWinCG.h. There may also be a PortIPhone.h. These port definition headers
Re: [webkit-dev] Proposal for a new way to handle porting #ifdefs
We pursued the same goal for a couple of years. Since our porting targets are various middleware CE platforms, we had to identify and adapt WebKit needs at a better grained level than platform. In order to do this we collected all dependencies in a Browser Abstraction Layer (BAL directory). The configuration is handled by a Base directory (definition of types, platform specifications) and we use CMake to define platform specificities (and it's a great cross- platform tool). Sure the BAL model has still improvements ahead of it, but it has the merit of existing, being widely tester on a quite wide range of targets, configurations and libraries. Regards Mario Le Friday 01 May 2009 01:12:54 Maciej Stachowiak, vous avez écrit : I think our set of porting macros has become somewhat confused. Originally, our idea was that a port represents primarily adaptation to a particular platform. However, over time it has become clear that most of what is decided by a port is not platform adaptation, but rather policy decisions. For example, ports decide to have different features enabled, or to use different sets of system functionality on the same underlying OS. In addition, I think the catchall top-level PLATFORM create confusion, because it is not totally clear if they are policy decisions, platform adaptation decisions, or what. Third, it seems wrong that the policy choices of every port are represented as a bunch of ifdef tomfoolery inside a single Platform.h file. And fourth, many ports often run on the same OS, but with a different set of choices - for example on Mac OS X it is possible to build the Mac, Chromium, Gtk, Qt and Wx ports (at least). Therefore, I propose that we change as follows: 1) Strictly separate platform adaptation (mandatory to run on a given OS, compiler, or CPU at all) from policy choices (what features to enable, what optional libraries to use). 2) Phase out PLATFORM macros completely - each use should be converted to a policy choice, or a platform adaptation decision. 3) Instead of ports being defined by a top-level PLATFORM macro, I propose that each port should have its own header file to define policy decisions. For example, I'd propose that the system Mac OS X WebKit should use PortCocoa.h, and the WebKit used by Safari for Windows should use PortWinCG.h. There may also be a PortIPhone.h. These port definition headers would live in their own top-level WebKit module. Each one would be completely owned by whoever is generally considered the owner of a given port. Because related ports on different platforms may wish to share policy choices, it's ok for Port headers to include shared headers for some choices. For example, all Apple-maintained ports may include PortApple.h. We could go even further and have PortDefault.h to make default choices of what features are enabled, that ports would have to explicitly override. 4) Platform adaptation macros would still be defined in Platform.h based on sniffing the environment, this would include things like the compiler, the underlying OS, available libc functions, and so forth. Platform adaptation macros would be: OS() - underlying operating system; only to be used for mandated low- level services like virtual memory, not to choose a GUI toolkit Examples: OS(UNIX) - Any Unix-like OS OS(DARWIN) - Underlying OS is the base OS X environment OS(FREEBSD) - FreeBSD OS(WIN) - Any version of Windows OS(WINCE) - The embedded version of Windows COMPILER() - the compiler being used to build the project Examples: COMPILER(GCC) - GNU Compiler Collection COMPILER(MSVC) - Microsoft Visual C++ COMPILER(RVCT) - ARM compiler HAVE() - specific system features (headers, functions or similar) that are present or not Examples: HAVE(MMAP) - mmap() function is available HAVE(ERRNO_H) - errno.h header is available HAVE(MADV_FREE) - madvise(MADV_FREE) is available Policy decision macros would be: USE() - use a particular third-party library or optional OS service Examples: USE(SKIA) - Use the Skia graphics library USE(CG) - Use CoreGraphics USE(V8) - Use the V8 JavaScript implementation USE(CFNET) - Use CFNetwork networking USE(NSURL_NET) - Use NSURLConnection-based networking USE(APPKIT) - Use AppKit views and events USE(GTK) - Use Gtk+ USE(QT) - Use Qt USE(QUICKTIME) - Use the QuickTime media engine USE(QTKIT) - Use the QuickTime media engine via the Mac QTKit API USE(QUICKTIME_WIN) - Use the QuickTime media engine via its Windows API ENABLE() - turn on a specific feature of WebKit Examples: ENABLE(ACCESSIBILITY) - Enable support for assistive technologies (currently wrongly a HAVE) ENABLE(XSLT) - Include XSLT support
[webkit-dev] leak
Hello, I seen in Changeset 3810, you force a leak, it's the same thing for the cache and others parts in webCore, I would understand why you want leak some part of code ? regards, -- Mario Bensi Join OWB team on freenode IRC, channel #owb Web-enabler for CE devices www.pleyo.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] leak
yes it's r38104, sorry. I seen also this in cache : ~Cache(); // Not implemented to make sure nobody accidentally calls delete -- WebCore does not delete singletons. it's also to make shutdown faster ? this can create a big leak, no ? Mario Le mardi 04 novembre 2008 22:04:39 David Kilzer, vous avez écrit : On Tue, 11/4/08, mario bensi [EMAIL PROTECTED] wrote: I seen in Changeset 3810, you force a leak, it's the same thing for the cache and others parts in webCore, I would understand why you want leak some part of code ? Do you mean r38104? http://trac.webkit.org/changeset/38104 This change was made to prevent destructors from being called on shutdown, both to prevent random crashes (since the order in which the destructors are called is non-deterministic) and to make shutdown faster. They are leaks only in the strictest sense of the term since only one instance of them is ever created, and it's held in a static variable. Dave -- Mario Bensi Join OWB team on freenode IRC, channel #owb Web-enabler for CE devices www.pleyo.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] changes to FrameView
Hi Luka, you can use view-hostWindow()-platformWindow() Mario Le dimanche 12 octobre 2008 17:36:40 Luka Napotnik, vous avez écrit : Hello. I had a patch that calls containingWindow() in a WebCore::FrameView object. But now I get the error: class WebCore::FrameView has no member named 'containingWindow' Can please someone tell me what's the equivalent method for containingWindow() now. Greets, Luka -- Mario Bensi Join OWB team on freenode IRC, channel #owb Web-enabler for CE devices www.pleyo.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Canvas
Hi, I have look lot of #PLATFORM in WebCore/html/Canvas* and it's very difficult to read the code and if it's platform dependant, i don't understand why it's not in plaform directory IMHO, I think it's better to do d pointer and implement the d pointer in WebCore/platform/graphics/... or implement the platform part in an other file for example CanvasRenderingContext2DMac.cpp/CanvasRenderingContext2DQt.cpp/CanvasRenderingContext2DGtk.cpp what do think of that ? -- Mario Bensi Join OWB team on freenode IRC, channel #owb Web-enabler for CE devices www.pleyo.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
