Re: [webkit-dev] bit field error on wince

2008-01-22 Thread Maciej Stachowiak 


On Jan 21, 2008, at 10:35 PM, ledwinka wrote:

During my work on porting s60 webcore to wince, I found there is a  
css bug

in render_style.h file, here is the struct define


You're probably better off basing a port on something more recent  
(like trunk or the Safari 3 branch) since many windows platform/ 
compiler issues like this have already been resolved.


 - Maciej




   struct NonInheritedFlags {
   bool operator==( const NonInheritedFlags &other ) const {
   return (_effectiveDisplay == other._effectiveDisplay) &&
   (_originalDisplay == other._originalDisplay) &&
   (_bg_repeat == other._bg_repeat) &&
   (_overflow == other._overflow) &&
#if NOKIA_CHANGES
   (_inputRequired == other._inputRequired) &&
#endif
   (_vertical_align == other._vertical_align) &&
   (_clear == other._clear) &&
   (_position == other._position) &&
   (_floating == other._floating) &&
   (_table_layout == other._table_layout) &&
   (_page_break_before == other._page_break_before) &&
   (_page_break_after == other._page_break_after) &&
   (_styleType == other._styleType) &&
   (_affectedByHover == other._affectedByHover) &&
   (_affectedByActive == other._affectedByActive) &&
   (_affectedByDrag == other._affectedByDrag) &&
   (_pseudoBits == other._pseudoBits) &&
   (_unicodeBidi == other._unicodeBidi);
 }

   bool operator!=( const NonInheritedFlags &other ) const {
   return !(*this == other);
   }

   EDisplay _effectiveDisplay : 5;
   EDisplay _originalDisplay : 5;
   EBackgroundRepeat _bg_repeat : 2;
   EOverflow _overflow : 4 ;
#if NOKIA_CHANGES
   bool _inputRequired : 1 ;
#endif
   EVerticalAlign _vertical_align : 4;
   EClear _clear : 2;
   EPosition _position : 2;
   EFloat _floating : 2;
   ETableLayout _table_layout : 1;

   EPageBreak _page_break_before : 2;
   EPageBreak _page_break_after : 2;

   PseudoId _styleType : 3;
   bool _affectedByHover : 1;
   bool _affectedByActive : 1;
   bool _affectedByDrag : 1;
   int _pseudoBits : 6;
   EUnicodeBidi _unicodeBidi : 2;
   } noninherited_flags;

On wince platform , any code access to bit field in this struct ,  
such as


EDisplay _effectiveDisplay : 5;

will produce asm code like this

EDisplay dis = noninherited_flags. effectiveDisplay;

mov r3 lsl #27
mov r3 asr #27
str r3 [sp]  // write to stack variable

this problem is the ASR instruction. If _effectiveDisplay contain a  
value
big than 0x0f, such as 0x1x, the ASR instruction will cause the high  
bits
fill with 1 , for example, if _effectiveDisplay equal EDisplay::NONE  
or

EDisplay::INLINEBOX,  EDisplay dis will EQUALS -14 or -13, not a valid
value.

How to solve this problem? thanks a lot!



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

re: [webkit-dev] bit field error on wince

2008-01-22 Thread ledwinka 
Thanks a lot!
I only search bug reports associated to s60 branch before.
I will post my patch to s60 branch when done the work around.g

-邮件原件-
发件人: Adam Roben [mailto:[EMAIL PROTECTED] 
发送时间: 2008年1月22日 22:49
收件人: ledwinka
抄送: webkit-dev@lists.webkit.org
主题: Re: [webkit-dev] bit field error on wince

On Jan 22, 2008, at 1:35 AM, ledwinka wrote:

> this problem is the ASR instruction. If _effectiveDisplay contain a  
> value
> big than 0x0f, such as 0x1x, the ASR instruction will cause the high  
> bits
> fill with 1 , for example, if _effectiveDisplay equal EDisplay::NONE  
> or
> EDisplay::INLINEBOX,  EDisplay dis will EQUALS -14 or -13, not a valid
> value.
>
> How to solve this problem? thanks a lot!

Oliver Hunt has already fixed this problem in a few places in WebCore.  
For one example, see
. Something similar will probably work here. Filing a bug and  
posting a patch on  would be much appreciated!

-Adam


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] webkit test suite help

2008-01-22 Thread Mark Rowe 


On 23/01/2008, at 01:56, syed mehdi wrote:

I got the qt3-dev-tools installed on my ubuntu machine and tried to  
build webkit, but got following errors:

any clue


You need qmake from Qt 4.  Please read the documentation at either  or  for  
further information about how to build.  If you had Google'd for the  
error message you received in relation to WebKit (eg ) you would have found this answer too.


Kind regards,

Mark Rowe



smime.p7s
Description: S/MIME cryptographic signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] webkit test suite help

2008-01-22 Thread syed mehdi 
I got the qt3-dev-tools installed on my ubuntu machine and tried to build
webkit, but got following errors:
any clue

[EMAIL PROTECTED]:~/WebKit/code# dpkg -l | grep qt3
ii  libavahi-qt3-1 0.6.10-0ubuntu3.4Avahi QT3
integration library
ii  libqt3-mt  3.3.6-1ubuntu6.4Qt GUI
Library (Threaded runtime version), V
ii  qt3-dev-tools  3.3.6-1ubuntu6.4Qt3
development tools
[EMAIL PROTECTED]:~/WebKit/code# WebKitTools/Scripts/build-webkit --gtk
Calling 'qmake CONFIG+=gtk-port CONFIG-=qt -r
OUTPUT_DIR=/root/WebKit/code/WebKitBuild/Release
/root/WebKit/code/WebKit.pro CONFIG+=release CONFIG-=debug' in
/root/WebKit/code/WebKitBuild/Release

***Unknown option -r
Usage: qmake [mode] [options] [files]

   QMake has two modes, one mode for generating project files based on
some heuristics, and the other for generating makefiles. Normally you
shouldn't need to specify a mode, as makefile generation is the default
mode for qmake, but you may use this to test qmake on an existing project

Mode:
-project   Put qmake into project file generation mode
   In this mode qmake interprets files as files to
   be built,
   defaults to *.c; *.ui; *.y; *.l; *.ts; *.h; *.hpp;
*.hh; *.H; *.hxx; *.cpp; *.cc; *.cxx; *.C
-makefile  Put qmake into makefile generation mode (default)
   In this mode qmake interprets files as project files
to
   be processed, if skipped qmake will try to find a
project   file in your current working directory

Warnings Options:
-Wnone Turn off all warnings
-Wall  Turn on all warnings
-Wparser   Turn on parser warnings
-WlogicTurn on logic warnings

Options:
 * You can place any variable assignment in options and it will
be * * processed as if it was in [files]. These assignments will
be parsed * * before
[files]. *-o
fileWrite output to file
-unix  Run in unix mode
-win32 Run in win32 mode
-macx  Run in Mac OS X mode
-d Increase debug level
-t templ   Overrides TEMPLATE as templ
-tp prefix Overrides TEMPLATE so that prefix is prefixed into
the value
-help  This help
-v Version information
-after All variable assignments after this will be
   parsed after [files]
-cache fileUse file as cache   [makefile mode only]
-spec spec Use spec as QMAKESPEC   [makefile mode only]
-nocache   Don't use a cache file  [makefile mode only]
-nodepend  Don't generate dependencies [makefile mode only]
-nomoc Don't generate moc targets  [makefile mode only]
-nopwd Don't look for files in pwd [ project mode only]
-norecursive   Don't do a recursive search [ project mode only]
Failed to setup build environment using qmake!


Thanks & Regards
Syed

On Jan 17, 2008 11:07 AM, Mark Rowe <[EMAIL PROTECTED]> wrote:

>
> On 17/01/2008, at 16:36, syed mehdi wrote:
>
> > I already tried executing "./WebKitTools/Scripts/run-webkit-tests --
> > gtk" but it gives usage info like:
>
>
> That's because you're not using the revision you claimed to be using!
>
> - Mark
>
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] bit field error on wince

2008-01-22 Thread Adam Roben 

On Jan 22, 2008, at 1:35 AM, ledwinka wrote:

this problem is the ASR instruction. If _effectiveDisplay contain a  
value
big than 0x0f, such as 0x1x, the ASR instruction will cause the high  
bits
fill with 1 , for example, if _effectiveDisplay equal EDisplay::NONE  
or

EDisplay::INLINEBOX,  EDisplay dis will EQUALS -14 or -13, not a valid
value.

How to solve this problem? thanks a lot!


Oliver Hunt has already fixed this problem in a few places in WebCore.  
For one example, see . Something similar will probably work here. Filing a bug and  
posting a patch on  would be much appreciated!


-Adam

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Runtime JSObject

2008-01-22 Thread David Carson 

On Jan 22, 2008, at 6:48 AM, Ashish Agrawal wrote:


Hi David,

Hi Ashish,




i am working on the same problem with Ankush.

We tried your solution and it worked, but we have one additional
problem, WebFrame::windowObjectCleared() is triggered for each frame
refresh so our handler gets called each time.


Not sure how this is a problem as IIRC the JS interpreter is created  
new each time a frame is loaded, inc reloads. So you would need to  
reattach each time. In my code, I manage the list of attached handlers  
in this function, and just re-attach them at this point.





Before our handler is called, the frame gets destroyed and we see a
segmentation fault in our handler.
It is hard to tell what your handler is doing to cause the sigsegv,  
could it be running and trying to call into JS after the frame is  
destroyed? If this is the case, you could listen for the frame load  
events and stop running when a frame load occurs.


Cheers
Davidc




Can you suggest any way by which prevent calling of our handler for  
each frame refresh.


Thanks
Ashish



On Jan 19, 2008 6:05 PM, David Carson <[EMAIL PROTECTED]> wrote:
Ankush,
I have run into this same problem too, and I was pointed to
WebFrame::windowObjectCleared(). If you re-attach your handler in that
method, everything will work, including frames and iframes.

For Mac look at:
WebKit/mac/WebCoreSupport/WebFrameLoaderClient.mm
WebKit/mac/WebCoreSupport/WebFrameBridge.mm
Windows:
WebKit/win/WebFrame.cpp
Gtk:
WebKit/gtk/WebCoreSupport/FrameLoaderClientGtk.cpp

Cheers
Davidc

On Fri, Jan 18, 2008 at 10:48 AM,  <[EMAIL PROTECTED]> wrote:
>
> Hi Ankush,
>
> Not sure if this is exactly the right way to do this, or what your  
looking

> for, but I think something like the following might work.
>
> KJS::Window* window  = KJS::Window::retrieveWindow(frame);
> if (window) {
> ExecState* exec = window->interpreter()->globalExec();
> window->put( exec, "your object name here", your object here,
> KJS::DontDelete );
> }
>
> Thanks
> Joe
>
>
>
> -Original Message-
> From: ankush tiwari
> Sent: Jan 18, 2008 7:55 AM
> To: webkit-dev@lists.webkit.org
> Subject: [webkit-dev] Runtime JSObject
>
> Hi All,
>
> We are creating a run time JSObject "myImplementation" by using  
the NPN
> framework (C binding) available in webkit. Currently we are facing  
a problem
> that our object is not getting recognized when we navigate to a  
new page.

>
> (Note: Our object is not released, its just not getting recognized  
in the

> new page's interpreter context)
>
> We want to retain our object till the time the interpreter is  
valid but we
> are not able to do so. We observed that for every script handler a  
context
> is created and if we put our code in KJSProxy::evaluate and insert  
our

> object every time its working fine.
>
> But this way we are creating too many unnecessary instances of our  
object.

>
> Can someone suggest a better way for retaining the object  
throughout the

> interpreters life cycle?
>
> Thanks,
> Ankush.
>
> ___
>  webkit-dev mailing list
>  webkit-dev@lists.webkit.org
>   http://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Runtime JSObject

2008-01-22 Thread Ashish Agrawal 
Hi David,

i am working on the same problem with Ankush.

We tried your solution and it worked, but we have one additional
problem, WebFrame::windowObjectCleared() is triggered for each frame
refresh so our handler gets called each time.

Before our handler is called, the frame gets destroyed and we see a
segmentation fault in our handler.

Can you suggest any way by which prevent calling of our handler for each
frame refresh.

Thanks
Ashish



On Jan 19, 2008 6:05 PM, David Carson <[EMAIL PROTECTED]> wrote:

> Ankush,
> I have run into this same problem too, and I was pointed to
> WebFrame::windowObjectCleared(). If you re-attach your handler in that
> method, everything will work, including frames and iframes.
>
> For Mac look at:
> WebKit/mac/WebCoreSupport/WebFrameLoaderClient.mm
> WebKit/mac/WebCoreSupport/WebFrameBridge.mm
> Windows:
> WebKit/win/WebFrame.cpp
> Gtk:
> WebKit/gtk/WebCoreSupport/FrameLoaderClientGtk.cpp
>
> Cheers
> Davidc
>
> On Fri, Jan 18, 2008 at 10:48 AM,  <[EMAIL PROTECTED]> wrote:
> >
> > Hi Ankush,
> >
> > Not sure if this is exactly the right way to do this, or what your
> looking
> > for, but I think something like the following might work.
> >
> > KJS::Window* window  = KJS::Window::retrieveWindow(frame);
> > if (window) {
> > ExecState* exec = window->interpreter()->globalExec();
> > window->put( exec, "your object name here", your object here,
> > KJS::DontDelete );
> > }
> >
> > Thanks
> > Joe
> >
> >
> >
> > -Original Message-
> > From: ankush tiwari
> > Sent: Jan 18, 2008 7:55 AM
> > To: webkit-dev@lists.webkit.org
> > Subject: [webkit-dev] Runtime JSObject
> >
> > Hi All,
> >
> > We are creating a run time JSObject "myImplementation" by using the NPN
> > framework (C binding) available in webkit. Currently we are facing a
> problem
> > that our object is not getting recognized when we navigate to a new
> page.
> >
> > (Note: Our object is not released, its just not getting recognized in
> the
> > new page's interpreter context)
> >
> > We want to retain our object till the time the interpreter is valid but
> we
> > are not able to do so. We observed that for every script handler a
> context
> > is created and if we put our code in KJSProxy::evaluate and insert our
> > object every time its working fine.
> >
> > But this way we are creating too many unnecessary instances of our
> object.
> >
> > Can someone suggest a better way for retaining the object throughout the
> > interpreters life cycle?
> >
> > Thanks,
> > Ankush.
> >
> > ___
> >  webkit-dev mailing list
> >  webkit-dev@lists.webkit.org
> >  http://lists.webkit.org/mailman/listinfo/webkit-dev
> >
> >
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev