Doing Xojos job with re-verifying bugs in new Feedback

It’s good to see that a web based Feedback finally is coming. But please tell me why I should do even more work for Xojo:

Sometime next year we intend to update the system such that when as case has had no activity in many months, the system will automatically ask the user if this case is still relevant. If they indicate that it is, the case will remain open. If not, it will close.

There are bugs in the system that are 10 years old and are still relevant. It’s Xojo’s job to check if a bug is still relevant or not. That’s not our job as users. We do the testing already.


Yeah, I’m really not a fan of this policy either. There are so many that just get ignored through no fault of our own. After we tell the system that it’s still relevant, will it do something to get an engineer’s attention on it? I expect not, in which case this “feature” just becomes a war of attrition. Eventually, the user will forget to reverify and Xojo can clear it from their plate despite never having done anything with it.

Edit, here’s a perfect example: <> “Parameters of URLConnection.SendingProgressed are named wrong.”

The case has been verified as reproducible by Xojo, yet nothing has happened with it. Should I really have to reverify this bug every six months? No. It’s not my fault nothing is happening with it.

I mean, I get it, sometimes bugs get fixed as side effects of other changes. But that does not happen enough to warrant pestering us.


Don’t like it either. Clearly workload reduction without the work it seems.

How about the system asks all of the users who added points to the case in addition to the original author…

EDIT: Would likely be lots of messages in any given month so may be over whelming

After all the work of reporting a bug, providing a sample project, maybe some screenshots and screen casts, writing a description of what we are doing, proofing which IDE versions and which OS is concerned, often struggling around with without any comment closed cases because not even our description and step by step instructions were read exactly and therefore the error can not be reproduced …

So after we do all this work for Xojo (yes - most of this work should be Xojo’s part) we also have to confirm every few months that the bug is still relevant.
This literally screams to simply confirm all requests with “YES”.


I disagree here. When filing a bug report for any app, the responsibility is on the reporter to make sure the information is clear. Xojo needs to know how to reproduce the bug. That is 100% on the reporter, because otherwise Xojo might take the wrong steps and either fail to verify it or maybe even verify a different bug.

Yup, this is going to happen. What I worry about is users writing important Xojo bugs and then leaving Xojo. Those bugs are going to be lost.

And yes, it’s our job to write bugs that can be reproduced.

That’s right - totally agree with you.
Often it gives the impression that Xojo itself does not even try the provided demo projects, screenshots, etc. and only asks on suspicion whether this or that could work.

A good example of how customer policy should not be:

I guess such a policy works only in the U.S. … do this in Europe and you have to close your business in a few months.

This happens often … but hey … we have a Pro Plus license.
So simply write an Email to Xojo … let these cases double or triple check … produce some extra work for Xojo and then get these things fixed.


63136 is a feature I’m super happy about.

Random example for really old bug: <> 12072 - Xojo crashes when C++ raises exception in out of memory situation . From 2009! Rank 51. Who knows if Josh Hill is still using Xojo.

1 Like

Not a big difference really. Now instead of they just ignoring the bug and leave it there OPEN for years, now they will close it if you are not constantly replying that you are still interested in the bug being fixed. :upside_down_face:

Closed could mean, you need to file another one. Many people won’t do that since they could find that closed shows that xojo is not fixing it… causing bugs to be unreported after that.

Even the priority system seems wrong. Some things like project types ands saving should be #1 then IDE and layout editor #2 etc since we still have for example the “true” vs true fighting in xojo_project files and many such other ide-written-save-changes-by-design we still have more work to do (manual reviewing git stuff). If those where never there one could have had more time to file reports. I’m not saying it is bad or non functional, just that it seems ineffcient.


So you have a bug, you can’t reproduce but xojo may he able to find a cause in code or at least investigate. They simply close the case because of no example project, that isn’t even possible for one to reproduce? A clear video was made (screen recording) to show the issue.

I think this is the wrong way to apoach it. It’s like there is no activity around those cases at all. Seems to me like it’s not worth my time to file any case.


We often think exactly like this.
We don’t file bug reports anymore which we can’t reproduce because we know that they are simply getting closed without even thinkin about it or investigating it.

With the exception of IDE crashes where an automated case is generated.
There we write 3-4 words what we were doing. But strictly speaking, we could save ourselves the work, since these cases are simply closed without a sample project anyway.

On the other hand if we don’t file cases nothing changes…


I’m in the same boat, and I know many others that have expressed the same feeling.

Unfortunatelly for xojo the users grown tired of the current system is taken as “Everityng is awesome, no one is complainig”, No votes, no bug fixes :man_facepalming:t2:

1 Like

In my experience, they don’t just close it. Your video may give them enough of a clue to reproduce it, but odds are it will not. So what should happen here? The case ends up amounting to “something is wrong.” If it can’t be reproduced, it can’t be fixed.

1 Like

Normally, there’s a closed reason indicated. If I check a given bug and find one with a status like “Closed—User didn’t confirm the bug is still there since 6 months”, I won’t blame Xojo thinking they just don’t want to fix the bug.

And I still prefer having cases automatically closed (where one can create a new case if necessary) than so much cases left open for years, should we have to choose between the two options.
Closing automatically means Xojo will focus on what’s known to be active. Both the users and Xojo will have a better visibility of what’s actively reported.
If something has been closed by mistake, because a user hasn’t confirmed the bug, someone more active in using Xojo may just create another case; that doesn’t frighten me.

Can’t reproduce can’t fix implies there had not been enough willingness to fix the issue same as feature requests. In xojo’s terms willingness is on the forums, mass compaints or high fb ranking. But that means there is Always A Way.

1 Like

I think the main issue is that Feedback is just not working good/stable/easy for everyone. Most devs i know think it’s too hard to find their way trough feedback app. I have numerous crashes, disconnections etc. Basicly so much i’ve given up to even use it. Not to mention 75%(about) cases are just closed because even we can’t reproduce them. Meaning we put more energy in than we’d even get out… we only filed such cases mostly because we had a requirement for them.

1 Like

I dislike this change.

For Apple we have the same as they come back automatically for a new OS release and ask whether the bug still exists on the new OS version. So it may just get closed because we don’t reply.

Already we have too often cases get closed, because someone put in a question and nobody replies within 10 days.


They don’t just close them. It “looks” like they just close them. We know xojo works on issues, they respond to them!

I don’t know what you’re trying to say. “Can’t reproduce can’t fix” doesn’t imply anything. It means there is no test case. There is no way to confirm that the bug is fixed. Sure, somebody could look at code they think might be to blame, and make a change that they think might fix it, but that’s not the same thing at all. What do you put in the release notes? “Made some changes that might fix X, but we don’t know for sure.” We’ve all been in situations like this, I know, but Xojo is a large product with a team of developers and dozens of reports filed daily. You cannot expect them to just make changes willy-nilly without some sort of test case.

In any software, if you can’t reproduce a bug, you can’t know it has been fixed. Maybe you fixed it, or maybe you’re just failing to trigger it. No way to know for sure.