WebPositive doesn't properly draw HTML buttons.

[Giova84]

hrev50440

Well, I have an html file which contains some html buttons as following:

<a href="#apps" class="class1"/><button>Apps</button></a>

But, using WebPositive, you can also check by yourself here:

​http://www.w3schools.com/tags/tryit.asp?filename=tryhtml_button_test

When the page is loaded, WebPositive, doesn't draw these buttons; you have to scroll the page, but most of the time is not enough, because at the next scrolling, the button will be erased.

QupZilla shows how these buttons should be drawed:

​http://funkyimg.com/i/2eLgP.png

[Pete]

I'm not seeing this -- except for the demo page you link to. You're right -- I see nothing (except usually a black pane) when I try that site with WebPositive. However, if I download the exact script they show and load that into W+ locally, it works fine. (I also tried copying the test file to my site and accessing it remotely. Works there, too.)

Also I copied the line you quote with the button enclosed in an anchor tag, and that has no problems in W+ either.

Looking on the web, it sounds as if "button" has had problems with various browsers, but I'm not sure what's triggering your case.

[Giova84]

Hi Pete, I just experience this trouble only with Web+, also if the html page is local; try to go to my web site and scroll to the bottom the long index page, then back to the top: with Web+ I always trigger this trouble, where the buttons disappears.

[Pete]

Ahh. I can reproduce it -- but only with your web page, and a recent WebPositive! My test page looks similar in structure (if a lot simpler) but it doesn't exhibit the effect under any circumstances. I downloaded your entire front page, first in my older pre-PM system, and the W+ there seems to work perfectly. Transferred over to PM, and the newer W+ behaves exactly as you describe. (Actually the button texts don't vanish -- just don't look like buttons any more.)

OK... I just pasted your buttons into my test file, and they behave as they do on your page! My test button right above them doesn't!! Hmm. Move the test button below the others, and it shares the disease. So I guess I was just lucky with a single button right at the top.

Took that test file back to my older system, and it has no problem. Seems to need the newer W+.

[sneaky]

I think that unstyled native widgets in the DOM (buttons, text inputs...) are not being painted with haiku platform style. Setting a different background or border in CSS is getting the widget drawn correctly.

<style>button { background: #ccc; color: black; }</style>

Putting a style element like above at the top of the page causes the 3d border effect to appear correctly.

[pulkomandy]

Native buttons are drawn, but there is an issue with the computation of the invalidation rectangle when transformations are used. Somehow the drawing method thinks it is outside the visible area, and does not draw itself.

You can get everything working properly if you invalidate the whole page everytime, but then it becomes super slow because everything is redrawn for example when you scroll a page - where currently, the existing page content is scrolled and only the newly exposed area is drawn.

[nephele]

Please retest with ​https://git.gryphno.de/nephele/haikuwebkit/commit/dc4fe4446097edc0d4b177c2ab2b439896c84bd1

[madmax]

As I see it, this is a problem in ControlLook, not in webkit.

​https://review.haiku-os.org/c/haiku/+/4457 (unfinished, but enough for testing, and also needs ​https://review.haiku-os.org/c/haiku/+/4455)

[nephele]

There was some discussion about irc on this, it seems the Decorator implemetnation is indeed incorrect. but I don't think it makes sense to draw the rect, and then clip it to rect. The Bview that is passed already knows about the clipping region.

In my testing simply removing the clipping calls (on the decorator site) worked fine aswell, this aproach would probably be the better one, since app_server already clips acording to the BView anyway?

In any case, webkit should not pass rect as updaterect but rather pass view->Bounds()

[pulkomandy]

I have commented on the Gerrit changes about the main points, and what I remember of how we expected this to work when we added view transforms. This should be better documented, possibly before we attempt any change and further confuse things.

[madmax]

Replying to nephele:

Please retest with ​https://git.gryphno.de/nephele/haikuwebkit/commit/011fd13722bee5df64c41a6a22420b6d7b015d46

Seems to work, except with menu buttons (the popups are right), like the ones here in trac for issues filters, when they are outside the bounds before scrolling. This is probably due to stuff like ​this in HaikuControlLook, and not your patch. It also does not show the background of clicked buttons with the Be control look correctly, but again that is probably a problem in BeControlLook or InvertRect.

I guess similar changes are needed for other be_control_look uses, both in RenderThemeHaiku.cpp and in ScrollbarThemeHaiku.cpp, as it's not just buttons suffering this.

[nephele]

I'll wait on ​https://review.haiku-os.org/c/haiku/+/4457 for now, and hopefully after that get some pointers to what the "correct" invocation should be for webkit to fix those calls then.

[pulkomandy]

I wrote some documentation about the correct thing to do and the different coordinate spaces already in hrev55500.

[nephele]

Should be fixed with: ​https://github.com/haiku/haikuwebkit/pull/23/commits/f65f4af0413dfcf8b0612f7d9bdc2ee959a6d7c9

[nephele]

Webkit now behaves correctly.

It may still happen in some cases because of the HaikuControlLook, so leaving this open for now.

​https://review.haiku-os.org/c/haiku/+/4457

[madmax]

Fixed for the different in-tree control looks in hrev56943, hrev56944 and hrev56955.