Closed mialondon closed 11 years ago
Running IE10 in IE9 mode did not reproduce the error, but that's unreliable. It's unclear to me why it would run differently on the dev and production servers, since the code is the same. Is anyone capable of running IE9?
On 21 August 2013 04:08, Mia notifications@github.com wrote:
As reported in a comment on my blog post http://openobjects.blogspot.co.uk/2013/08/so-we-made-thing-announcing-serendip-o.html?showComment=1376958336884
'I was looking forward to trying this out but apparently it doesn't like me :( At http://serendipomatic.org/ clicking the 'magic' button just clears the text I put in the box. At http://dev-serendipomatic.herokuapp.com the text stays, but clicking the button doesn't do anything. Sad, because I like this idea.
Running IE9 on Windows 7.'
I don't have IE9 or Windows 7 so can't replicate it.
— Reply to this email directly or view it on GitHubhttps://github.com/chnm/serendipomatic/issues/144 .
Scott Kleinman Professor of English Director, Center for the Digital Humanities California State University, Northridge
I just sat down with one of our library staff who was having trouble with this exact issue. She's running IE 9 in Windows 7, and I can verify that it behaves in exactly the way that Mia described.
OK, I know the code that's involved. I'll have a look on Thursday or Friday (my next open window). It looks like I'm still assigned to this on.e
On 3 September 2013 12:54, Brian Croxall notifications@github.com wrote:
I just sat down with one of our library staff who was having trouble with this exact issue. She's running IE 9 in Windows 7, and I can verify that it behaves in exactly the way that Mia described.
— Reply to this email directly or view it on GitHubhttps://github.com/chnm/serendipomatic/issues/144#issuecomment-23741764 .
Scott Kleinman Professor of English Director, Center for the Digital Humanities California State University, Northridge
This might be a result of the same origin policy on a JQuery.get() request. A possible solution can be found at http://mvcdiary.com/2013/01/16/jquery-ajax-request-not-working-in-ie9/. I'm noting it here as a reminder to be pursued this weekend.
We're doing a GET request for that? Seems like there should be a simpler way to do it...
That's what I thought, but Eli and I had a lot of trouble getting this function to work properly. I don't remember whether the current code is his contribution or mine. But I'll look into it this weekend.
On 9 October 2013 07:20, Rebecca Sutton Koeser notifications@github.comwrote:
We're doing a GET request for that? Seems like there should be a simpler way to do it...
— Reply to this email directly or view it on GitHubhttps://github.com/chnm/serendipomatic/issues/144#issuecomment-25974692 .
Scott Kleinman Professor of English Director, Center for the Digital Humanities California State University, Northridge
I took a quick look at this - I think we should be using the placeholder attribute for the default text instead of initial as we currently are ( https://github.com/chnm/serendipomatic/blob/master/smartstash/core/forms.py#L11 ).
Unfortunately, it seems that placeholder isn't supported by IE9. However, there are existing solutions to fix that -- here's one that looks like it might be a nice solution (if you do some searching you'll find some other options): http://kamikazemusic.com/quick-tips/jquery-html5-placeholder-fix/
Hmmm...I didn't even know about the placeholder attribute, but I see that it is definitely not supported by IE9. But are you sure we are using it? The default text is in a
On 10 October 2013 07:52, Rebecca Sutton Koeser notifications@github.comwrote:
I took a quick look at this - I think we should be using the placeholder attribute for the default text instead of initial as we currently are ( https://github.com/chnm/serendipomatic/blob/master/smartstash/core/forms.py#L11).
Unfortunately, it seems that placeholder isn't supported by IE9. However, there are existing solutions to fix that -- here's one that looks like it might be a nice solution (if you do some searching you'll find some other options): http://kamikazemusic.com/quick-tips/jquery-html5-placeholder-fix/
— Reply to this email directly or view it on GitHubhttps://github.com/chnm/serendipomatic/issues/144#issuecomment-26060330 .
Scott Kleinman Professor of English Director, Center for the Digital Humanities California State University, Northridge
I was thinking we could switch to a placeholder and I thought when I looked it up textarea could use it (that seems close to the functionality we want). However, when your comment prodded me to think about it again, I remembered-- we don't really want placeholder functionality, because we do want to actually submit the default text if the user doesn't modify it.
Instead of using a GET, we should find a simpler way to make the initial value available to the javascript. Either save it at some point (document load time? when the form is cleared?), or update the django template to store it in a javascript variable.
Looking more closely, it seems there is a discrepancy between the release and development versions. The release version simply deletes hard-coded default text when you click on the textarea. The development version loads the default text by ajax and then checks whether the content of the textarea is the same. If it is, the text is deleted. This appears to prevent the user from deleting their own text by clicking on the textarea. It would be pretty easy to put the default text into a variable on page load instead of the ajax request. I'll test that to see if the ajax request is somehow breaking the script in IE9.
The other possibility that I can see is the fact that we have both an onclick call and an onsubmit call in the form. Perhaps IE9 is having trouble dealing with that.
On 13 October 2013 17:02, Rebecca Sutton Koeser notifications@github.comwrote:
I was thinking we could switch to a placeholder and I thought when I looked it up textarea could use it (that seems close to the functionality we want). However, when your comment prodded me to think about it again, I remembered-- we don't really want placeholder functionality, because we do\ want to actually submit the default text if the user doesn't modify it.
Instead of using a GET, we should find a simpler way to make the initial value available to the javascript. Either save it at some point (document load time? when the form is cleared?), or update the django template to store it in a javascript variable.
— Reply to this email directly or view it on GitHubhttps://github.com/chnm/serendipomatic/issues/144#issuecomment-26230278 .
Scott Kleinman Professor of English Director, Center for the Digital Humanities California State University, Northridge
And now I'm looking at the original error report:
It seems to me that the first order of business might be to move the onclick call to the textarea instead of the form element. I'll try that, and we'll see how it goes.
On 13 October 2013 21:27, Scott Kleinman scottkleinman@gmail.com wrote:
Looking more closely, it seems there is a discrepancy between the release and development versions. The release version simply deletes hard-coded default text when you click on the textarea. The development version loads the default text by ajax and then checks whether the content of the textarea is the same. If it is, the text is deleted. This appears to prevent the user from deleting their own text by clicking on the textarea. It would be pretty easy to put the default text into a variable on page load instead of the ajax request. I'll test that to see if the ajax request is somehow breaking the script in IE9.
The other possibility that I can see is the fact that we have both an onclick call and an onsubmit call in the form. Perhaps IE9 is having trouble dealing with that.
On 13 October 2013 17:02, Rebecca Sutton Koeser notifications@github.comwrote:
I was thinking we could switch to a placeholder and I thought when I looked it up textarea could use it (that seems close to the functionality we want). However, when your comment prodded me to think about it again, I remembered-- we don't really want placeholder functionality, because we do\ want to actually submit the default text if the user doesn't modify it.
Instead of using a GET, we should find a simpler way to make the initial value available to the javascript. Either save it at some point (document load time? when the form is cleared?), or update the django template to store it in a javascript variable.
— Reply to this email directly or view it on GitHubhttps://github.com/chnm/serendipomatic/issues/144#issuecomment-26230278 .
Scott Kleinman Professor of English Director, Center for the Digital Humanities California State University, Northridge
Scott Kleinman Professor of English Director, Center for the Digital Humanities California State University, Northridge
I pushed a potential fix to github last night, but the dev server has not updated for testing. Any ideas why?
On 13 October 2013 21:43, Scott Kleinman scottkleinman@gmail.com wrote:
And now I'm looking at the original error report:
- On the release version: clicking the submit button clears the text but doesn't submit the form (i.e. only onclick is firing).
- On the dev version: clicking the text doesn't do anything (i.e. neither onclick nor onsubmit is firing).
It seems to me that the first order of business might be to move the onclick call to the textarea instead of the form element. I'll try that, and we'll see how it goes.
On 13 October 2013 21:27, Scott Kleinman scottkleinman@gmail.com wrote:
Looking more closely, it seems there is a discrepancy between the release and development versions. The release version simply deletes hard-coded default text when you click on the textarea. The development version loads the default text by ajax and then checks whether the content of the textarea is the same. If it is, the text is deleted. This appears to prevent the user from deleting their own text by clicking on the textarea. It would be pretty easy to put the default text into a variable on page load instead of the ajax request. I'll test that to see if the ajax request is somehow breaking the script in IE9.
The other possibility that I can see is the fact that we have both an onclick call and an onsubmit call in the form. Perhaps IE9 is having trouble dealing with that.
On 13 October 2013 17:02, Rebecca Sutton Koeser <notifications@github.com
wrote:
I was thinking we could switch to a placeholder and I thought when I looked it up textarea could use it (that seems close to the functionality we want). However, when your comment prodded me to think about it again, I remembered-- we don't really want placeholder functionality, because we do want to actually submit the default text if the user doesn't modify it.
Instead of using a GET, we should find a simpler way to make the initial value available to the javascript. Either save it at some point (document load time? when the form is cleared?), or update the django template to store it in a javascript variable.
— Reply to this email directly or view it on GitHubhttps://github.com/chnm/serendipomatic/issues/144#issuecomment-26230278 .
Scott Kleinman Professor of English Director, Center for the Digital Humanities California State University, Northridge
Scott Kleinman Professor of English Director, Center for the Digital Humanities California State University, Northridge
Scott Kleinman Professor of English Director, Center for the Digital Humanities California State University, Northridge
I noticed there was an error in the travis-ci build last night, and I fixed at least one problem with it. But it looks like something with the automatic deploy is broken - not sure what the "anvil" error is, but I'll see if I can fix it.
https://travis-ci.org/chnm/serendipomatic/builds/12506540
Side note: I think I'm the only one currently getting the build notices from travis-ci (it sends an email if the build is broken and then when the first time it passes after being broken). If any one else is interested in getting these emails, let me know and I'll figure out how to add you.
If it's not too complicated to add me, I'd like to get those, also.
It doesn't look like the automatic deploy is fixed yet (my commits have not updated), so I'm holding off on further attempts to fix the IE9 incompatibiltiy issue until then.
On 17 October 2013 11:27, mfrazer notifications@github.com wrote:
If it's not too complicated to add me, I'd like to get those, also.
— Reply to this email directly or view it on GitHubhttps://github.com/chnm/serendipomatic/issues/144#issuecomment-26534607 .
Scott Kleinman Professor of English Director, Center for the Digital Humanities California State University, Northridge
I tried an alternate deploy strategy in the travis-ci build, and it looks like it worked. Please test, and let me know if you're still having problems.
Yes, that worked.
As a reminder, in IE9 the default text was not disappearing at the first click or the "Make some magic!" button was not submitting. If anyone has access to IE9, please test the dev server and let me know if the problem is resolved.
On 17 October 2013 13:16, Rebecca Sutton Koeser notifications@github.comwrote:
I tried an alternate deploy strategy in the travis-ci build, and it looks like it worked. Please test, and let me know if you're still having problems.
— Reply to this email directly or view it on GitHubhttps://github.com/chnm/serendipomatic/issues/144#issuecomment-26546815 .
Scott Kleinman Professor of English Director, Center for the Digital Humanities California State University, Northridge
Ok. I confirmed on another machine. It definitely looks a little wonky ... however, in looking at your comments above, I can verify that, in dev on IE9 now
(original comment) I do have access to IE9. Things look a little wonky - see the capture. The second row of images is displaying in a column on the home page.
I've created issue #152 for the single column display.
@mfrazer, do the textarea and submission button work all right now?
On 17 October 2013 13:35, mfrazer notifications@github.com wrote:
I do have access to IE9. Things look a little wonky - see the capture. The second row of images is displaying in a column on the home page.
[image: capture]https://f.cloud.github.com/assets/3811953/1355704/7f130fc2-376b-11e3-910a-7829c06b9a42.PNG
— Reply to this email directly or view it on GitHubhttps://github.com/chnm/serendipomatic/issues/144#issuecomment-26549944 .
Scott Kleinman Professor of English Director, Center for the Digital Humanities California State University, Northridge
No, sorry that was poor phrasing on my part in the earlier comment.
The Make Some Magic button isn't working.
Nothing happens, but a box does appear towards the top of the window...let me get a screen grab for you.
Does the default text disappear when you click the text area?
On 17 October 2013 14:20, mfrazer notifications@github.com wrote:
No, sorry that was poor phrasing on my part in the earlier comment.
The Make Some Magic button isn't working.
— Reply to this email directly or view it on GitHubhttps://github.com/chnm/serendipomatic/issues/144#issuecomment-26554071 .
Scott Kleinman Professor of English Director, Center for the Digital Humanities California State University, Northridge
Yes, the text disappears when you click the text area.
Here's a screen grab of what happens when you click on Make Some Magic...the shaky blue circle is around a box that appears only after clicking the button.
The code is , which should not submit at all since there doesn't seem to be any javascript submitting it. I bet that's at the root of the problem. I'm going to try to change it to <input type"submit" id="magic-button" class=" magic" value="Make some magic!"/> to see if that does any good. I'll put an asterisk next to the button so that you can see when the dev server has updated.
On 17 October 2013 14:25, mfrazer notifications@github.com wrote:
Yes, the text disappears when you click the text area.
Here's a screen grab of what happens when you click on Make Some Magic...the shaky blue circle is around a box that appears only after clicking the button.
[image: capture2]https://f.cloud.github.com/assets/3811953/1356174/889c7a0e-3772-11e3-9831-4804134911a4.PNG
— Reply to this email directly or view it on GitHubhttps://github.com/chnm/serendipomatic/issues/144#issuecomment-26554412 .
Scott Kleinman Professor of English Director, Center for the Digital Humanities California State University, Northridge
I am not in my workroom today (with IE9), but had a colleague test and he verified that the button is working. I will test again before going to production, but I think that last change fixed it.
Ok. I have verified the functionality again on my machine. However, the change in code broke the styling on the button - in Firefox and IE. The button in Firefox is the same except gray instead of green. In IE, it's a straight up Windows button.
Looks to me like the css with the styling for the button is on line 500 of base.css - it's keying off "button" and the new code removes that.
That's good news. I didn't change the Zotero "Go" button, and I need to remove some commented out code, but I'll do that and then close this issue (re-open it if your tests prove that it's still not working).
On 18 October 2013 07:59, mfrazer notifications@github.com wrote:
I am not in my workroom today (with IE9), but had a colleague test and he verified that the button is working. I will test again before going to production, but I think that last change fixed it.
— Reply to this email directly or view it on GitHubhttps://github.com/chnm/serendipomatic/issues/144#issuecomment-26602553 .
Scott Kleinman Professor of English Director, Center for the Digital Humanities California State University, Northridge
I was aware of the css issue and didn't bother to fix it until I knew that the code change worked. I'll go ahead and do that with my final tweaks and then close the issue.
On 18 October 2013 09:45, mfrazer notifications@github.com wrote:
Ok. I have verified the functionality again on my machine. However, the change in code broke the styling on the button - in Firefox and IE. The button in Firefox is the same except gray instead of green. In IE, it's a straight up Windows button.
Looks to me like the css with the styling for the button is on line 500 of base.css - it's keying off "button" and the new code removes that.
— Reply to this email directly or view it on GitHubhttps://github.com/chnm/serendipomatic/issues/144#issuecomment-26611042 .
Scott Kleinman Professor of English Director, Center for the Digital Humanities California State University, Northridge
You can leave the issue open and assign it to me. I want to verify it production once it's deployed, then I'll close it.
Thanks!
I have just fixed the css and deleted old code; the changes should deploy to the dev server soon. I've assigned this issue to @mfrazer.
Verified that make some magic works and text box clears on click.
As reported in a comment on my blog post http://openobjects.blogspot.co.uk/2013/08/so-we-made-thing-announcing-serendip-o.html?showComment=1376958336884
'I was looking forward to trying this out but apparently it doesn't like me :( At http://serendipomatic.org/ clicking the 'magic' button just clears the text I put in the box. At http://dev-serendipomatic.herokuapp.com the text stays, but clicking the button doesn't do anything. Sad, because I like this idea.
Running IE9 on Windows 7.'
I don't have IE9 or Windows 7 so can't replicate it.