Opened 4 years ago

Last modified 14 months ago

#12890 new bug

WebPositive doesn't properly draw HTML buttons.

Reported by: Giova84 Owned by: pulkomandy
Priority: normal Milestone: Unscheduled
Component: Applications/WebPositive Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Platform: All



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:

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:

Change History (5)

comment:1 by Pete, 4 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, 4 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, 4 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, 14 months 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, 14 months 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.

Note: See TracTickets for help on using tickets.