I think I might’ve found several bugs in WebPositive. Most of them are graphical weirdness - text not rendering, window tearing, but that might be related to the fact that I am running Haiku in VMware.
There is one possible bug tho that isn’t related to VMware - when you do “Open link in a new tab”, the page has an empty URL input, but loads the page with no problems.
URL input is focused and empty:
I looked thru the code, and it seems like the problem is caused by the line 1372 in function BrowserWindow::CreateNewTab - fURLInputGroup->MakeFocus(true);. It puts the URL input in focus, and since it is the active window now - WebPositive automatically switches to the new tab once it’s opened - it causes test in URLInputGroup::SetText (line 670) to fail after the page has loaded and the program attempts to set the text BrowserWindow::LoadFinished (line 1532).
I am posting here since I am not sure what is the right thing to do - it seems like that line was put there on purpose, yet it isn’t really useful and just breaks things.
P. S. I am using hrev51200, gcc2_hybrid, but the first time I encountered this problem was all the way back in hrev50595.
I think there is already a ticket for it. It is half finished code from me.
The idea was to lock the URL bar when the user is editing it. Quite often, while I was typing in an URL, WebPositive would decide that it was a good time to handle a redirect and change the URL it was showing, erasing my editing work. So, I added a (too simple) solution: whenever the URL text box is focused, WebPositive is not allowed to change the URL.
As you noticed, this doesn’t quite work. In particular, when opening a new tab, the URL is always focused. The idea is that you can open a new blank tab and type an URL immediately to go somewhere. However, it is also focused when opening a tab with already an URL to load inside it (for example “open in new tab” on a link).
Now, what are the ways to fix it? I see 3 possible solutions:
-
Do not focus the URL view when opening a new tab, if we know we are going to load something already. This does not feel very clean and the problem could happen in other cases if you accidentaly leave the URL bar focused
-
Be smarter about locking the URL bar. Instead of doing it once it is focused, only lock when the user actually has started changing the text. This way, the lock doesn’t create a problem unless you already have something valuable in the URL bar. Possibly there should also be a timeout, so if you edited the URL long ago, but did not valdiate it (press enter or so), it could be erased too.
-
Remove this URL locking completely, and live with the fact that sometimes the user will get annoyed when trying to enter an URL and the browser will erase it.
I prefer solution 2. Anyone wants to make a patch to cleanup behind me?
I can try doing that 
How would I go about creating a timer tho? I’ve found BMessageRunner, but I don’t think it really fits here - some timer object in which the remaining time can be changed (reset the timeout every time the user presses a key) would be better.
Also, how big should the timeout be? I am thinking ~5 sec.
BMessageRunner sounds appropriate. You can use SetInterval to change the time. I think you can use SetCount(0) to stop it, then SetCount(1) to restart it (and it restarts at the initial interval if you do that).
5 seconds after the last key press sounds ok, maybe a bit too long. I guess we will have to exeperiment a little to see how it behaves.
