Dropdown menu crashes application in off-screen rendering mode

[magicyuuu]

Dropdown menu crashes application in off-screen rendering mode

[GoogleCodeExporter]

When loading cefpython homepage RenderHandler.GetScreenRect() is called 3 
times, it is also called when going to Downloads page. When dropdown menu is 
expanded there is a call to RenderHandler.GetViewRect(). I think that we need 
to provide implemntations for these callbacks in panda3d example. There is also 
RenderHandler.GetScreenPoint().

Original comment by [email protected] on 27 Dec 2012 at 4:38

• Changed title: Dropdown menu crashes application in off-screen rendering mode
• Changed state: Accepted

[GoogleCodeExporter]

A call to RenderHandler.GetViewRect() is made just before the crash, it is 
probably critical to implement it.

Original comment by [email protected] on 27 Dec 2012 at 6:37

[GoogleCodeExporter]

Did you try implementing these 3 callbacks?

Original comment by [email protected] on 29 Dec 2012 at 3:36

[GoogleCodeExporter]

Yes i did, however implementations for some reason are never executed in my 
case. Assertion kills app first.

My code:

    def GetViewRect(self, browser, rect):
        print 'GetViewRect'
        width  = self.texture.getXSize()
        height = self.texture.getYSize()
        rect.append(0)
        rect.append(0)
        rect.append(width)
        rect.append(height)
        return True

    def GetScreenRect(self, browser, rect):
        print 'GetScreenRect'
        return self.GetViewRect(browser, rect)

    def GetScreenPoint(self, browser, viewX, viewY, screenCoordinates):
        print 'GetScreenPoint'
        screenCoordinates.append(viewX)
        screenCoordinates.append(viewY)
        return True

P.S. this code is from my own app where web view covers whole screen

Original comment by [email protected] on 29 Dec 2012 at 9:02

[GoogleCodeExporter]

I've created a topic on CEF Forum regarding this matter:
http://magpcss.org/ceforum/viewtopic.php?f=6&t=10343

Original comment by [email protected] on 30 Dec 2012 at 4:27

[GoogleCodeExporter]

I see now what is going, when you click on dropdown menu, the paintElementType 
is PET_POPUP (normally PET_VIEW) and the buffer contains data for drawing only 
popup widget (dropdown menu).

We probably need to call Browser->GetImage() to get the buffer with the 
dropdown menu being drawn when paintElementType is PET_POPUP.

Original comment by [email protected] on 2 Jan 2013 at 11:24

[GoogleCodeExporter]

We need to draw the popup widget ourselves by modyfiying the buffer.

Original comment by [email protected] on 2 Jan 2013 at 11:36

[GoogleCodeExporter]

oh right, just as in my berkelium code!
i assume its best to be done in c++ for efficiency too right?

Original comment by [email protected] on 3 Jan 2013 at 8:52

[GoogleCodeExporter]

In OnPaint the dirtyRects have x=0, y=0 for PET_POPUP, how do we know where to 
draw it? How does CEF know where we drew it, whether the menu expanded to the 
top / bottom / left or right? How do we forward mouse click/move events on that 
popup to CEF?

Original comment by [email protected] on 3 Jan 2013 at 2:38

[GoogleCodeExporter]

By looking at my old berkelium-related code i see widgets having their own 
buffers and changes being drawn to those buffers. That explains x and y being 0.

Later on they are drawn on main buffer after main window is drawn on that 
buffer.
I do not recall any special requirements for event passing to widgets. To my 
knowledge it was done automatically in berkelium so most likely it is the case 
with CEF too.

Code im speaking of is one you already saw: 
http://pastebox.it/file/fAGxcpGbXvu8fhDsaO6lcBEXgHk/8EEvDA.cpp

Original comment by [email protected] on 3 Jan 2013 at 2:48

[GoogleCodeExporter]

We will have to analyze cefclient sources as Marshall sugessts here:
http://magpcss.org/ceforum/viewtopic.php?p=15259#p15259

cefclient sources are here:
http://code.google.com/p/chromiumembedded/source/browse/branches/1271/cef1/tests
/cefclient/

What interests us is probably:

- clientplugin.cpp
http://code.google.com/p/chromiumembedded/source/browse/branches/1271/cef1/tests
/cefclient/clientplugin.cpp

- osrenderer.cpp
http://code.google.com/p/chromiumembedded/source/browse/branches/1271/cef1/tests
/cefclient/osrenderer.cpp

- osrplugin.cpp
http://code.google.com/p/chromiumembedded/source/browse/branches/1271/cef1/tests
/cefclient/osrplugin.cpp

- osrplugin_test.cpp
http://code.google.com/p/chromiumembedded/source/browse/branches/1271/cef1/tests
/cefclient/osrplugin_test.cpp

Original comment by [email protected] on 3 Jan 2013 at 9:58

[GoogleCodeExporter]

Yup its pretty much what i said. :)


I started work on implementation of popup rendering. It is basically mimicking 
whats in osrenderer.cpp.
Now i propose moving code that fills buffer with pixel data from 
RenderHandler_OnPaint to ClientHandler::OnPaint. Main reason - its easier there 
to store popup rect obtained from ClientHandler::OnPopupSize, and that rect is 
needed in OnPaint callback to draw popup on image buffer. So 
RenderHandler_OnPaint would become only a wrapper function like for example 
RenderHandler_OnPopupShow.

What do you think? Maybe you have better alternative in mind?

Original comment by [email protected] on 10 Jan 2013 at 11:15

[GoogleCodeExporter]

We should not modify ClientHandler, like I said on the cefpython
group, any c++ code should go to cpp_utils/ directory. All methods
of RenderHandler have Browser object which has a method for storing
custom data (rect you mention) associated with this browser, see 
SetUserData() & GetUserData():

http://code.google.com/p/cefpython/wiki/Browser

Remember also that the void* buffer passed to OnPaint() method is
read-only.

In PaintBuffer class (paint_buffer.pyx) we malloc our own buffer,
but it is free'd before GetString() method returns, for drawing
popups we need to store this buffer between OnPaint() calls. We
should extend PaintBuffer for drawing popups, also drawing of a
popup should be optional, we should not begin any drawing until
some method like GetString() is called on the PaintBuffer object.

It probably should not be allowed to use different mode or origin
when calling GetString() in subsequent OnPaint() calls.

Original comment by [email protected] on 10 Jan 2013 at 3:33

[GoogleCodeExporter]

In CEF 3 Kivy OSR example SELECT boxes were fixed by injecting a javascript
boxes library on webpages, that transform normal <SELECT> elements into 
javascript
ones. See this commit:

https://code.google.com/p/cefpython/source/detail?r=a9fd89cc746176806a542829e2a1
bdd484d8f0b6

Original comment by [email protected] on 18 Sep 2013 at 8:44

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

CEF 1 is deprecated.

Original comment by [email protected] on 10 Aug 2014 at 6:57

• Changed state: WontFix