[Bug] reload button don't works after send a form with post method
Bug? please test this page www.questotrentino.it/test.asp and press the go button, after sent the form, the page can't be reloaded with F5, ctrl+F5 or reload button.
Vivaldi 1.7.715.3 (Build ufficiale) (a 64 bit)
Sistema operativo Windows 10 pro 64bit
Known and unresolved bug.
This bug seems to have been around for a while https://forum.vivaldi.net/topic/5250/reload-refresh-source-post-method
Love Vivaldi but this is a show stopper for me....
Vivaldi 1.6.689.40 (Stable channel) (64-bit)
OS Mac OS X
Yes, the bug is slowing down daily work.
I try to ping the devs about this.
Reporting this bug more and more is not useful. Bug fixing speed is not relation to number of reports coming in -- would be nice if we could do it like this
@Gwen-Dragon Well what is it proportional to then?
@punchyrascal Please explain what you mean. I can't understand your answer, what is it related to? May be my english (non-native speaker!) is too bad!?
@Gwen-Dragon You say that order of bugs being worked on is not related to number of reports by users, so I am asking what is it related (proportional) to? Because I would imagine, that any company would work on the more-reported bugs first, since they apparently annoy more people than other bugs.
@punchyrascal On bugtrackers if there are many bugreports, that may increase the priority. But that will not lead to a fix.
Bany bugreports for the same bug will only increase the list of duplicates of a bug.
The priority of a bug is set by developers and the toFix list of the devs is not known.
I can ping a dev for some bugs and hope that may be fixed faster.
@punchyrascal - to be a bit more precise, the developers DO weigh how many people are suffering from a bug, and duplicate reports add to that weight.
That said, this is not a major factor in considering what order to fix things in. It is a factor, but not a major one.
More important are factors like: How difficult is the fix? What other things will the fix break? Does the fix move in a straight line toward the goals of Vivaldi, or is it a side trip? A nice-to-have? What other fixes need to be worked on to reach pre-determined goals? If we fix this for some reporters, are we going to piss off people who like things the way they are?
Example: users complain about font anti-aliasing. Another user complains certain font menus are too small. Well, anti-aliasing and font size are set by the system. Vivaldi only has options for style and minimum size in web pages. A developer thinks, "I could just increase the font size for that menu" and then thinks, "no, then we'll get a bunch of complaints for not using system settings." Does Vivaldi want to give everyone the size, style and clarity of fonts they want in both pages and the UI? Absolutely! Will this require thousands or tens of thousands of lines of code? For sure! Is it on a straight line between us and out immediate goals? Not right now. So an independent font-handling system for Vivaldi will have to wait.
@Ayespy I understand - being a developer myself. But this is neither a nice-to-have nor a side trip. It is clearly a bug, that breaks expected behavior and people complain about it being broken (for several versions now). I also know, that when you neglect bugs and user input and keep adding "exciting and new" features that hardly anyone wants or needs, you will end up with useless product with a ton of bugs that no one wants to use. But yeah, maybe you will have all the TODOs checked on your "exciting todo list"
@punchyrascal - of course it's a bug. And of course the team knows all of the things you pointed out. They have been successful browser-builders for over 20 years. Each of the "Things" I called out in my roll-call of factors, refers not to features or other items, but BUGs. Things that are expected to work, and don't. Vivaldi has a few thousand of them registered at this point. Some of them are of the importance that the next release can't be put out without them being fixed. Some of them are of the importance that even though releases may go out, these particular bugs must still be worked on steadily until they are fixed. Some have to be gotten to at some point, when time and resources permit. Some cannot be addressed until some additional major functionality (like, say, Vivaldi's own font-renderer) has been constructed. Some can't be fixed yet because they are blocked by a bigger, tougher bug. Some are things which, though they don't work, hardly affect anyone (for instance, reported in March of 2015 by a single person, and no one has noticed or reported it again since then, so it's obviously not bothering anyone) and so can be displaced by more important ones. Some are literally functionalities which, though a certain user expected it to work and it doesn't, is not considered of fundamental importance to the mission of a browser. That's a "nice-to-have." It's a bug, but only because Chrome (on which we're based) does it, so we're "supposed to" do it, but really, whatever. Certain low-popularity extensions not working in Vivaldi would, for instance, fall under this category.
Again, the developers obviously give weight to how many people are affected by a bug. But it's not the prime driver of what gets addressed first.
Could you at list give some ETA for the issue? I've changed several versions of this browser hoping that it was fixed (its STRs aren't obvious, so it took a time to find corresponding bug-reports and found out that noone tried to fix it). Its obviously not "nice-to-have" as for end user it should be no difference if there were some post calls as he most probably won't know this (this is a technical detail that should not worry end user). In addition not only Chrome but all browsers don't have this issue.
Could you at list give some ETA for the issue?
No, we dont know a ETA.
We get many reports about such issue.
And i always try to ping a developer about such important issue.