A bug’s life at Vivaldi
-
@gwen-dragon: @pesala:
What Pesala said is what also I thought immediately after reading the article, because I have the same experiences with bugs reporting.
The problem with rejecting bug reports is that no-one who has reported an error knows what's happening to it and what status it has. For this reason unnecessary duplicates appear.
We should get at least some answer (by Jira system) when more information is needed to fully understand the bug, and those reports shouldn't be rejected.
It's not about answering in comments, because this does not solve the problem. -
@gwen-dragon:
@pesala:I don't see VB-18100 as an issue. On the contrary, I like the fact that I can see what is currently being searched in the page when I hit F3.
Moreover, it can also be used as a visual confirmation that the search has been done. For example when the searched word has not been found. If no toolbar is displayed, it may be misunderstood.When the search is done, you hit ESC anyway, at least to remove the yellow highlights of the results. As the toolbar is closed when hitting ESC, having displayed it does not even impact the user actions.
-
As others here have mentioned it would be great if users could view the issue tracker. Knowing whether or not a report already exists will cut down on duplicates and knowing the status can allow the reporters to provide more info if necessary.
-
Let's note also that the Sopranos are doing a huge work of triaging the bugs. It's worth saying it.
I totally agree that the status of the bugs should be public, at least for those filed by the public. Not necessary their name, or even the discussion in it. But just their status.
Finally, Vivaldi believes that a "good bug" is a bug that'll be filed again. Even if the first one is closed (by mistake or not), if it impact multiple persons, if it's important enough, somebody else will file it, and thus, there is another chance of fixing it.
-
I'm interested in knowing about your automated regression tests. What tools do you use, how tests are written, etc.
-
what about the idea from VB-34514 ?
btw: thanks for this article
-
Making the bug tracker publicly accessible is also a matter of missing JIRA licenses. It's simply not possible without paying a huge amount of money here.
OTOH sending status updates to the reporter's mail address is very much possible. We have been discussing this internally a few times already and I'm going to continue being an advocate for this. -
Clearing 94% of bugs per month is impressive.
It makes this regression, which essentially ruins a unique Vivaldi feature, all the more mystifying as it nears its one-year anniversary:
https://forum.vivaldi.net/topic/15429/tab-cycling-and-tab-opening-issues-while-using-tab-stacksPesala has it right. That needs to happen in some form. To think that a fundamental regression could go this long seems to put it in the same boat as feature requests, where you might get it one year but no promises (though be sure to upvote!).
They're two completely different things. One already exists and is bleeding out. The other hasn't been born yet.
-
@guilimote said in A bug’s life at Vivaldi:
Moreover, it can also be used as a visual confirmation that the search has been done. For example when the searched word has not been found. If no toolbar is displayed, it may be misunderstood.
When the word is found, it is highlighted. In the event that the search term is not found, nothing happens in Opera. In Firefox, the Find in Page toolbar is opened.
@guilimote said in A bug’s life at Vivaldi:
When the search is done, you hit ESC anyway, at least to remove the yellow highlights of the results.
You can press Esc, but you can just leave the highlighted text highlighted as a place-marker, or click on the page to remove it.
-
This is an interesting discussion, since I made the same argument 2 years ago and nothing has improved. Obviously I recognize that Vivaldi is a proprietary project and a public tracker may be difficult, but I think bug tracking still needs be more reciprocal. Regardless of anyone's stance on the subject, the current handling of bugs is inadequate. This can be demonstrated to a degree by the number of bugs in this thread that @gwen-dragon has reopened. Bugs should be expected and many more critical bugs do get fixed relatively quickly but unfortunately Vivaldi's development seems more focused on adding features than resolving regressions.
It's depressingly amusing that Vivaldi's team is so interested in communicating with their user-base when it comes to feature requests, yet seems almost opposed to putting the same effort into resolving issues. All the features in the world don't mean anything if they don't work correctly. I'm not trying to be disrespectful, however I always see; "You wanted xyz", "We heard you", "We listened"... Well, We've been saying we want improved bug handling, Is anybody listening?
-
Well... the first thing to do would be not using 3rd party Cookies in here i guess... since i guess many peeps have those disabled.
And just a very small thing that you could do; enable back/forward function in speed dial folders, it's annoying that when you enter a folder, the mouse "back" doesn't work. -
@cail Actually, Vivaldi doesn't "use 3rd party cookies." They use a single login protocol to sign you in to two different domains at once - vivaldi.net, and vivaldi.com. It doesn't matter which side you sign in from, setting a "signed in" cookie on the other side will make that a 3rd party cookie. Half of the community content is in one domain, and half in the other. To "not use 3rd party cookies" they would have to either make you sign in to each domain separately, (which might create a problem using the same profile ID and password for two domains), or cram everything from both sides into a single domain. For my part, I'm not bothered by the current setup.
-
I've also filed bugs for UI changes/improvements in the past and inquired about their status only to learn they had been closed as Invalid/won't fix. However, I don't think that these were being ignored but rather taken into consideration for future improvements.
(Edit: I'm not talking about UI bugs that I've filed for things that broke unintentionally. Those usually do get fixed very quickly.)
To add to @Aronand 's followup, just because a bug gets closed in the bug tracker doesn't necessarily mean that it's dead. Bug reports, combined with feedback received from forum discussions and feature requests, do get incorporated into future releases.
So, filing bugs and discussing them here in the Forums really does work... even though it might sometimes take a while for our suggestions and feedback to become reality.
-
@cqoicebordel said:
Finally, Vivaldi believes that a "good bug" is a bug that'll be filed again. Even if the first one is closed (by mistake or not), if it impact multiple persons, if it's important enough, somebody else will file it, and thus, there is another chance of fixing it.
I'd replace the "that" with "if" - i.e. (...) if it is a "good" bug it will be filed again (...)
One of the problems of fixing bugs is that the developers need to be able to reproduce it so that they can see what is broken - which can be really difficult sometimes. There were some bugs that were in since years and got tons of bugreports, but it was still impossible to fix them, no matter how detailed the description of the reporter was and which additional data they sent - because nobody was able to reproduce them until someone finally stumbled upon the real trigger by accident (I think especially about one of those "sometimes" bugs)
-
@quhno said in A bug’s life at Vivaldi:
One of the problems of fixing bugs is that the developers need to be able to reproduce it so that they can see what is broken
I have seen a lot of bug reports (for other products) closed because the developers could not reproduce them. Often, this was because my report was too brief, or was misunderstood in some way. However, because I received a report that the bug had been closed, I was able to follow up immediately and convince them that there was indeed a bug.
There's a good chance that the same bug reported six months or a year later by someone else will just get closed again.
-
- Enter chrome://settings/content/cookies in the address bar
- allow:
[*.]vivaldi.net [*.]vivaldi.com
After that you can use the central login even with 3rd party cookies disabled.
-
@pesala said in A bug’s life at Vivaldi:
There's a good chance that the same bug reported six months or a year later by someone else will just get closed again.
As we usually don't close duplicate bug reports but set them as duplicate (provided the reporter has chosen a sensitive title and steps so that we can find the duplicate) we see if there are more reports about something - which definitely raises the awareness that there might indeed be something that causes it.
-
@hekel: Hey, all the feedback in this thread is very useful for us, we are listening
-
We have in house test automation system similar to RobotJS and AutoPy. It relies on visual pattern search, color search, image comparison and controls mouse, keyboard and touchscreen.
System is mostly written in JavaScript and uses Node.js, but a few platform specific and/or performance critical parts are written in a number of different languages form C to AppleScript.
It's mostly used by QA for automating interactive tests. We have over 22000 tests that catch over half of regressions. The rest is catched by QA, developers, Sopranos and users.
We run tests continuously on x64 machines running Windows, Linux and Mac and ARM development boards running Linux.
Besides that developers write Unit tests in Jasmine testing framework and those tests also help to catch regressions.
-
@gwen-dragon said:
@derday said in A bug’s life at Vivaldi:
VB-34514
I voted in bugtracker for this.
Hi, can you give me news on VB-32651?
Thank you.