Drag-N-Drop image upload compatibility with Ubuntu + Firefox. #339

merged 2 commits into from Jan 27, 2013

2 participants


just added one more argument to the if statement handling dropevent. it checks to make sure dt.types does not include type: files before sending it into the code block.


Oh? This short? I thought you had to add whole new clauses to the decision tree.

Did you edit the javascript? Or did you edit the coffeescript and generate the javascript?


Yup, this short. sorry if my English verbosity led you to believe otherwise... the only thing that was going wrong was that the drop was being passed into the code to generate a reference first thing, and then since it was an image it would fail and punt, so I just made it check that there were no files in the data transfer before passing it down. I suppose it could be done with a new clause that checks for the specific combination first and then executes accordingly.

Ultimately it seems like it would make sense to have some sort of browser/UI-check at the beginning of client.js, passing the result into a simple variable and then using that throughout the code in various top level conditionals. It doesn't make much sense now, but it might make things simpler down the road. Holistic solutions to specific problems, yeah?

Interestingly enough, the 'drag url into factory to create reference' doesn't work in the first place on UB/FF so I really don't know if I'm breaking something for other browsers, my hunch would be that a location field drag is unlikely to contain a 'Files' type in any scenario, so we should be good. I'm going to work on tweaking the code to actually make those references for me (in my browser the location field drag is nothing but plain text so it doesn't get handed to the reference-maker in the first place). While I'm at it I'll explore browser/OS checking and do some reading on how to code for widest compatibility.

I edited the javascript, which I now realize to be a faux pas... I basically was teaching myself js as I worked the problem and using coffeescript almost as comments more than as code. I'll do some research into coffee and re-render the solution/a better solution thusly.


same fix via coffeescript, still looking into alternatives for browserchecks etc.


Oops. Missed this coffeescript update during a busy week. Thanks for the adjustment.

@WardCunningham WardCunningham merged commit fcbbd43 into WardCunningham:master Jan 27, 2013

I had a little trouble with this commit. It seams that not binds tighter than in. I posted a fix 4840eb2.

This raises the question of how we can test this logic reliably. I'd like to collect a set of (continuously evolving) cases from a variety of browser/os combinations. One approach would be to collect info and then make decisions based on the info. We could then run a battery of collected infos agains the decision logic and be sure it makes the right decision in each case. Punt makes the first feeble attempt at collecting info.


I keep trying to look into best practices for browser compatibility, and keep getting distracted by new ideas for other things (ccnx, tent.io, and meshnets oh-my!). I like the idea of collecting error data from every failed attempt, either manually or in the form of code that automatically pulls the browser/version/OS data from visitors, or half-n-half (detailed coding info + a users description of error would be very nice).

((This is where I practice google-fu for a moment))

I found this Browserdetect script http://www.quirksmode.org/js/detect.html

Though in the first paragraph the author advises against using it to code for compatibility: http://www.quirksmode.org/js/support.html

What we run into is less about the browser supporting something we want to display and more about anticipating how the browser is going to present something the user wants to insert, so I'm on the fence about how much salt to take all this with, but in the interest of collecting data I'd say put the browserdetect inside of the punt definition, capturing the results as we do with "Types", and turn "unexpected Item" into a hardlink to a page on one of your wiki's. On said page, instruct user to move the punt over, type a short description of what they were trying to do, and [[Submit Changes]] If the user flow works as it does in my hand, every time someone encounters this error you'll get a submission that gives you a lot more information than what we're currently getting, and you'll probably find that by staying within the context of the wiki, more failures will be recorded than there are now, since folks won't have to come all the way over to github to tell us about it.

Whew, a little long winded on this one. I've been procrastinating far too long on this, as well as on some content writing for a little syndicate I'm trying to form on my SFW farm. I'm going to get to the latter, and then I'll try and test the former for you. If I find the user flow and the collected data to be as described, I'll post a link and you can decide whether you'd like a pull request.


This is good. Here is how it might work.

  1. Punt gives you better explanation and invites you to participate in a drop survey at, say, drop.fed.wiki.com.
  2. The survey contains a dozen Factory plugins with instructions as to what and how to drop things there.
  3. The user can review the the json of the local storage page before submitting the changes to the drop collector site.

This would remain a public reference for anyone hacking the Factory code.


Update: Got rudimentary browser-detect working inside of the punt, and unexpected item is now [[Unexpected Item?]]. though the factory plugin is now... less than elegant; I just tossed the entire script at the top of the factory code because I'm having trouble calling it from a separate file, so until I exercise some more google-fu/trial-and-error I don't want to commit it as it stands.

In the meantime, does this look like a solid data collection result? ('capable' refers to css3, I'll try to find a way to make that more explicit for commit)

I'd be happy to author a drop survey as well, though I'd like your input as to what sort of cases we could test... my imagination is coming up a few short of a dozen.


This looks useful. Let's make items of type "paragraph" instead of type "data". Its a little harder to see the metadata but it can be done through the ui. Then the text of the paragraph could even offer an explanation, something like:

Trouble: We detected the drop but cannot yet make sense of the information provided by your browser and operating system. Try something different. If you know that your drop should have worked and you want to file a bug report you can do so on [https://github.com/WardCunningham/Smallest-Federated-Wiki/issues github]

(You would read the hidden data by clicking on the journal entry and then double-clicking on the timestamp to see the item in the action that created it.)


OK, that seems straightforward enough. I'll try and have a polished commit by tomorrow.


github wont let me delete my comment entirely... still having trouble getting browserdetect as a separate script/ knowing where to put it (I'm thinking in client/lib?) but stackoverflow and I are becoming friends. thanks for your patience.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment