Possible IE9 issue?

[mialondon]

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.

[scottkleinman]

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 [email protected] 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//issues/144
.

Scott Kleinman
Professor of English
Director, Center for the Digital Humanities
California State University, Northridge

[briancroxall]

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.

[scottkleinman]

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 [email protected] 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//issues/144#issuecomment-23741764
.

Scott Kleinman
Professor of English
Director, Center for the Digital Humanities
California State University, Northridge

[scottkleinman]

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.

[rlskoeser]

We're doing a GET request for that? Seems like there should be a simpler way to do it...

[scottkleinman]

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 [email protected]:

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//issues/144#issuecomment-25974692
.

Scott Kleinman
Professor of English
Director, Center for the Digital Humanities
California State University, Northridge

[rlskoeser]

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/

[scottkleinman]

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 <textarea>, which doesn't take @Placeholder.
Unless it's something internal to Django...

On 10 October 2013 07:52, Rebecca Sutton Koeser [email protected]:

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//issues/144#issuecomment-26060330
.

Scott Kleinman
Professor of English
Director, Center for the Digital Humanities
California State University, Northridge

[rlskoeser]

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.

[scottkleinman]

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 [email protected]:

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//issues/144#issuecomment-26230278
.

Scott Kleinman
Professor of English
Director, Center for the Digital Humanities
California State University, Northridge

[scottkleinman]

And now I'm looking at the original error report:

1. On the release version: clicking the submit button clears the text but
   doesn't submit the form (i.e. only onclick is firing).
2. 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 [email protected] 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 [email protected]:

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//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

[scottkleinman]

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 [email protected] wrote:

And now I'm looking at the original error report:

1. On the release version: clicking the submit button clears the text but
   doesn't submit the form (i.e. only onclick is firing).
2. 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 [email protected] 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 <[email protected]

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//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

[rlskoeser]

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.

[mfrazer]

If it's not too complicated to add me, I'd like to get those, also.

[scottkleinman]

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 [email protected] 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//issues/144#issuecomment-26534607
.

Scott Kleinman
Professor of English
Director, Center for the Digital Humanities
California State University, Northridge

[rlskoeser]

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.

[scottkleinman]

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 [email protected]:

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//issues/144#issuecomment-26546815
.

Scott Kleinman
Professor of English
Director, Center for the Digital Humanities
California State University, Northridge

[mfrazer]

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

• clicking the text box clears the text
• clicking the Make Some Magic button does nothing.

(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.

[scottkleinman]

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 [email protected] 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//issues/144#issuecomment-26549944
.

Scott Kleinman
Professor of English
Director, Center for the Digital Humanities
California State University, Northridge

[mfrazer]

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.

[scottkleinman]

Does the default text disappear when you click the text area?

On 17 October 2013 14:20, mfrazer [email protected] 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//issues/144#issuecomment-26554071
.

Scott Kleinman
Professor of English
Director, Center for the Digital Humanities
California State University, Northridge

[mfrazer]

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.

[scottkleinman]

The code is Make some magic!
, 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 [email protected] 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//issues/144#issuecomment-26554412
.

Scott Kleinman
Professor of English
Director, Center for the Digital Humanities
California State University, Northridge

[mfrazer]

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.

[mfrazer]

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.

[scottkleinman]

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 [email protected] 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//issues/144#issuecomment-26602553
.

Scott Kleinman
Professor of English
Director, Center for the Digital Humanities
California State University, Northridge

[scottkleinman]

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 [email protected] 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//issues/144#issuecomment-26611042
.

Scott Kleinman
Professor of English
Director, Center for the Digital Humanities
California State University, Northridge

[mfrazer]

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!

[scottkleinman]

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.

[mfrazer]

Verified that make some magic works and text box clears on click.

#152 is still an issue, but closing this one.