Opened 8 years ago

Closed 19 months ago

#12890 closed bug (fixed)

WebPositive doesn't properly draw HTML buttons.

Reported by: Giova84 Owned by: pulkomandy
Priority: normal Milestone: R1/beta5
Component: Kits/Interface Kit Version: R1/Development
Keywords: Cc:
Blocked By: #18237 Blocking: #15449, #16158, #16754, #18366
Platform: All

Description

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

Change History (21)

comment:1 by Pete, 8 years ago

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.

comment:2 by Giova84, 8 years ago

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.

comment:3 by Pete, 8 years ago

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+.

comment:4 by sneaky, 6 years ago

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.

comment:5 by pulkomandy, 6 years ago

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.

comment:6 by pulkomandy, 3 years ago

Component: Applications/WebPositiveKits/Web Kit

comment:7 by pulkomandy, 3 years ago

Blocking: 15449 added

comment:9 by madmax, 3 years ago

Blocking: 16754 added

comment:10 by madmax, 3 years ago

Component: Kits/Web KitKits/Interface Kit

comment:11 by madmax, 3 years ago

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)

comment:12 by nephele, 3 years ago

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()

comment:13 by pulkomandy, 3 years ago

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.

in reply to:  8 comment:14 by madmax, 3 years ago

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.

comment:15 by nephele, 3 years ago

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.

comment:16 by pulkomandy, 3 years ago

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

comment:17 by nephele, 22 months ago

Blocked By: 18237 added

comment:19 by nephele, 22 months ago

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

comment:20 by madmax, 19 months ago

Blocking: 18366 added

comment:21 by madmax, 19 months ago

Milestone: UnscheduledR1/beta5
Resolution: fixed
Status: newclosed

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

Note: See TracTickets for help on using tickets.