The Haiku Project’s release coordinator for the R1/Beta3 release, kallisti5, has made the decision to bump back the release of R1/Beta3 by one week.
Good decision. Thanks for All the work.
It’s more important to “get it right”, and not embarrass ourselves, than to rigidly follow a release schedule.
Fully agree that is a wise decision since the remaining Web+ issue looks like a blocker.
I have no guarantees that the disappearing font issue will be fixed. I really want to get it fixed, but honestly nobody is 100% sure on the cause as of right now. The upcoming haikuwebkit-1.8.2 update will address several issues though.
I’m crossing my fingers and bugging everyone daily about it 
It may be caused by rectangle clipping. When I investigated WebKit and app_server drawing some time ago, I found that rectangle clipping use special handling and that handling is wrong. As workaround clipping can be rotated to a small angle to use polygon clipping instead of rectangle clipping.
Still some text disappearance issues with a newer build (WebKit 612.1.24) and latest Haiku patches - but some other issues are fixed over the older webkit 610.
The other issue someone mentioned is downloads. I’ve using Webkit to upload images/binaries - but some work was needed on downloads (bug(s) submitted).
Do you have an example code for that?
My understanding is that there are two completely independant clipping systems in app_server (mostly in https://git.haiku-os.org/haiku/tree/src/servers/app/DrawState.cpp )
One is region clipping. This can use a BRegion (only rectangles) and always works in screen space (ignoring transforms). This can be used to tell a window that other windows are overlapping, for example, but it is also possible to clip further (GetClippingRegion/ConstrainClippingRegion).
The other is picture based clipping. The idea is more to use a mask that is stored as a BPicture. This can be used not only for clipping, but also for alpha transparency effects if your picture has partially transparent pixels. As a side effect, your clipping shape can be antialiased. This is used in BView ClipToShape, ClipToPicture, and the corresponding “inverse” functions. Picture based clipping works with transforms, so it can be scaled, rotated, etc.
There is a special case in ClipToRect (called from BView::ClipToRect and ClipToInverseRect): https://git.haiku-os.org/haiku/tree/src/servers/app/DrawState.cpp#n474 if no transform is applied, it will optimize the clipping by using the region-based one (which is faster and uses less memory). But if there is a transform, the rect will be transformed, and if there is rotation or shear, it won’t be a rect anymore. So, in that case, shape clipping will be used. However, I don’t see how this can cause a problem, since the fast path with regions is used only when there is no transform at all? What’s missing here?
Can we get this change into beta 3? I remember more than one instance where reviewers were confused with the labels not updating.
I can queue it up. It might not make it into the release media (we really can’t risk introducing any more bugs before R1/beta3 comes out) But it would be a good R1/beta3 update.
It would be better than nothing of course but I don’t think reviewers would update their system first thing after a fresh install. It’s the review of the “image” after all, considering they mostly screencast everything from the install to first boot, then finding software to install.
Also, FWIW, let’s not rush the release. I’d like to think people here would also more like something stable than a meet-the-deadline thing.
is there an easy way to install without building from source?
Hi, beta3 has not been released, but you can find info on the test candidates here:
thanks very much
Is it possible to revert WebKit to previous working version if invisible text bug will be not solved in time? It will give too bad impression to users. Reverting is proposed on Russian chat.
Nope. If it was a smaller change, I would have immediately reverted. However:
Pretty much, none of this has been an easy call. I’m balancing keeping nightly images working, and keeping R1/beta3 working. We can’t delay r1/beta3 indefinitely. Alternative browsers like Otter exist in haikuports which might be a viable workaround.
I thought that branching haikuports for R1/B3 was part of the R1/Beta3 Timeline this time?
https://dev.haiku-os.org/wiki/R1/Beta3/Timeline
I probably missed the reason for it not being branched.
The builders run pre-release beta3 now, so technically we have beta3 haikuports but no longer a beta2 haikuports version.
There was a question mark next to it 