File upload doesn't refresh list in Edge browser

[aakison]

Upload a gcode file (haven't tried with others)
Watch upload progress bar
Upon completion, file list does not refresh.
I've seen this work in Chrome, but this is occurring in Edge.
There were some warnings in the Developer Tools window (although they don't look related).

[GitIssueBot]

Hi @aakison,

It looks like there is some information missing from your ticket that will be needed in order to process it properly. Please take a look at the Contribution Guidelines and the page How to file a bug report on the project wiki, which will tell you exactly what your ticket has to contain in order to be processable.

If you did not intend to report a bug, please take special note of the title format to use as described in the Contribution Guidelines.

I'm closing this one now as it is currently incomplete. Please feel free to comment here to request a reopen of this issue once you can provide all required information.

Best regards,
~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.

[aakison]

Wow, you guys really don't care about an easy to use system.

[foosel]

Make a suggestion how to make it easier than copy-pasting a readily provided template linked to from the top of every new issue form that asks the basic amount of information we need in order to process bug reports (exact version information, log files, ...) that doesn't amount to the team spending more time running after information from the user (or closing things that have already been answered in the FAQ or are just completely out of place here) than actually solving issues and adding functionality.

Always open for suggestions :)

What we have tried so far:

• Regularly following up with users to please provide the necessary data. Didn't work, was ignored by many, tickets cluttered up the bug tracker and made navigating complicated.
• Having the bot follow up with the users and auto-closing the ticket if the information still was missing after 14 days. Didn't work, was ignored by many, still clutter.
• Having the bot directly closing the ticket if the information is missing. As much as I personally hate that approach, it works best so far, people at least react more, less clutter.

This thing is not in place to bully people or make it complicated for them to report bugs - copy-pasting a template is all that's necessary. This is a piece of Open Source Software, under constant development, free of charge. It isn't too much to ask to at least provide us the necessary information to work with so we can make it better instead of having us running after that constantly, don't you think? ;)

[aakison]

First off, thank you for responding. I thought my reply would only be read by a 'bot as well.

Respectively though, no I don't agree.

Having a bot close an issue - having never been viewed by a human - is never the way to form a community. I don't want to "contribute" (I read that as pull requests to your repo) so I didn't dive through your entire repo find out all of the ins-and-outs, I just to make you aware of a problem that you may have not seen since Edge has only been out a week. If the information provided is sufficient, then great, prioritize it and possibly action it. If it is not, then a human should mark it as "Not Reproducible". Think about the other side:

• I use your project and find enough value to click on the "bugs" link you proudly put on the bottom of your application web page.
• It takes me to a list of issues and my issue is not there.
• I spend some time concisely describing a problem (note that a concise definition is harder than a long worded one).
• I can't give you a screenshot (since it is a lack of something rather than a wrong something) so I bother to capture the warnings the browser reports.
• I hit submit - this is my first introduction to a new project - one that I might in the future choose to contribute to.
• My e-mail inbox chimes in that all of my effort is not wanted since I didn't read the "fine print".

Your current system does not work. You've tried three things and two have them have failed in the past. Please accept this as the third one has failed as well. If you're agile, then you will embrace this as a learning experience.

So, now that I know someone is reading this, here's my suggestion:

1. Point the bugs link on the bottom of your app to the Git page that describes the process.
2. Simplify the process.

don't you think? ;)

[foosel]

having never been viewed by a human

That's not the case.

I didn't dive through your entire repo

That's not necessary. One click is all it takes.

form a community

I'm sorry, but this is a bug tracker. We have an active mailing list, we have an active Google+ Community (which the bot btw also links to). This here is the place to report bugs, and bug reports without all required information do not work, they help neither the reporter nor the maintainer.

a human should mark it

No. This simply doesn't scale for a project this size. This is exactly what was tried at first. It became absolutely unmanageable and it also lead to a problem you are overlooking: the bot doesn't care how often he has to tell people to please provide the necessary information and repeat itself in the process. Human beings who have to do that repeatedly, multiple times, each day, throughout each and every week of the year can become really really frustrated and angry and load off their frustration at people not being concise and providing all necessary information on the next unsuspecting offender. Either that, or just give up on providing support/answering tickets at all. That is pure poison for keeping maintainers motivated and open towards the user base.

Your current system does not work.

Given the fact that since the bot is in place I've been able to get back to actually work on the project again instead of using the major part of my time running after information and repeating myself, I'm sorry, I have to say it does work. People who are seeking support get redirected to places where they can get it (and get helped there, which I know since I naturally also monitor and participate at those places). People who are interested in collaborating on solving an issue at hand get the hint what is missing, provide it and then we tackle the problem together. The feedback I so far have gotten on the process is that while people (myself included) wish it wasn't necessary, it is understood that it does help in solving the core issue of people not reporting back or simply being in the wrong place. Time is a resource. This process saves time on issue handling and thus helps with having more time for actually adding value for the whole community. In fact, I'd go so far as to say that trying to handle that stuff manually would in fact be entirely unfair towards the community.

Point the bugs link on the bottom of your app to the Git page that describes the process.

That's a good idea. Given my previous experiences however, my guess is it still won't help. It's worth a try though.

[r89m]

Would it help to have the "Bugs" link in OctoPrint point here instead?

Pre-filling the items to be answered means people would have no excuse for missing sections (I realise this may break the bot in it's current form though)

[foosel]

Thank you for the suggestion, but I don't think this will work. Prefilling the bug template wouldn't help people who are in the wrong place at all or who could be helped faster by just looking into the faq. The thing currently linked at the top of each form not only explains what to do for bugs but also where to get support (not the job of the bug tracker), how to file feature requests, to please check the faq first etc. Prefilling the template would - from my experience with this project and its users so far - lead to people filling in the version field with "The one on my OctoPi image", state as their problem that their webcam isn't recognized, put as log file the sentence "I don't know where to find that" and so on. And before you say "can't be" - all this has happened. Happened a lot before the bot. Still happens, but way less often.

I'll look into swapping that link with a dialog that includes all the information and try if a "new issue" link that actually prepopulates the log file, version, etc isn't possible down the road. That's been on my to-do list anyhow since a while, ideally with some "make a screenshot" thing. But the bot stays, at least until that proves to work as well.

I am well aware that the situation isn't ideal. It's a compromise to leave air to breathe for the maintainers while still providing the users with the necessary information they need to proceed or to tell them what information they need to provide for their issue to get handled.

You might have noticed that it's only a handful of people ever replying to tickets here. Most users sadly vanish once their own problems are solved and don't help others (or at least that's my impression over the last 2.5 years with this project). From a user perspective I'd prefer it that I get a fast reply to my issue, telling me if something is missing so I'm still in the proper setting to add that (e.g. I still have the server up and running anyhow) or know I'm in the wrong place altogether than having to wait for until when a human being is up, aware of the issue and had the time and focus to tell me exactly the same.

[r89m]

Very good points. If only my Python weren't so dire I'd try to lend a hand!

[Salandora]

@shaggythesheep my python was well zero when I started helping with "small" things, and today well It's not best but it's good enough to get some bugs fixed and to understand the code. Just read abit in the OctoCode and try python is really easy.

Back to Topic:
I do have W10 on my PC, will check what is going on here and then try to reproduce and fix it.

[aakison]

@Salandora Thank you for being on-topic. A key human desire is to be heard and recognized and I feel that you're the first one to 'hear' me.

@foosel RE "Most users sadly vanish", yes you can be assured that whether this issue is addressed or not, I will disappear. I recommend the following read: http://www.amazon.com/Complaint-Gift-Recovering-Customer-Loyalty/dp/1576755827/ref=sr_1_1?ie=UTF8&qid=1438907086&sr=8-1

[foosel]

@aakison I'm sorry to see you go, but you also took next to no visible effort to try to understand the points I was making, instead just taking the course to feel offended and ignored (which nobody did btw) and trying to blame me for all that. Meanwhile your critique regarding the way users find their way to this tracker was already started on by @shaggythesheep in #1013 and we are discussing it over there.

This here is not a product that you bought and that's done for profit. It is not, and if you are treating it as such you are comparing apples and oranges. It is a joint effort of people working together, most of them in their free time, in order to create something free and usable for everyone. For that to work there are guidelines in place, and most people who do contribute have absolutely no problem following them and understand why they are there.

Yes, helpful input is always appreciated. But not every input is helpful, at least not if you needed to first run after data to figure out if it was helpful in the first place. At some point, things become more time consuming than they are worth it.

You are taking this personal. I'm sorry to see that, but I can't do anything about it - if every single contributor of OctoPrint behaved this way, nothing would get done.

I've asked you repeatedly to see the bigger picture here, instead of focusing on your wounded pride. You don't want to do that, that's your right, so good luck.

Maybe one link for you too while you are on the way out: http://opensoul.org/99ways/ I'm working on the project part of these slides constantly. All I'm asking is users to look into the part that is summed up in this slide deck under "motivation of maintainers".

---

The issue at hand seems to be caused by edge aggressively caching even xhr responses from the API. Fixing it should be done by just globally setting the non caching headers on all API responses (afterResponse). @Salandora, if you want to tackle this, feel free.

While the OP still hasn't provided the version he is running, after a quick test yesterday the issue seems to reproduce under 1.2.4 and 1.3.0-dev and probably other versions as well.

[aakison]

@foosel "foosel reopened this 30 minutes ago". Reflection... Adaptation... Progress.

[Salandora]

@foosel thanks for the hint.
@aakinson dont get me wrong I'm not doing this for you. I do it for the rest of the users. If it were just you I wouldnt even tackle this. You do not provide informations so I have to get them all on my own this takes my time. My free time which could be spend somehow else then searching for informations to a bug you could already have provided by filling up a simple to use template.
But because it is a bug every Edge user will experience I do tackle this for the whole community. If I would have a way to just let the fix not work for you be sure I would excessivly use this way for all bug fixes I do.

[aakison]

@Salandora I don't need it - it would be a "nice-to-have". The workaround is to refresh the screen. The bug report was for you, not for me. Perhaps that is the misunderstanding - I was never asking for anything. I was giving you the gift of knowledge that your system doesn't work as intended on Edge.

[foosel]

Fix is merged on devel, also be back ported to maintenance branch and hence part of the upcoming 1.2.5 release.