[Building Sakai] Bug in Firefox 4 and 5 in Samigo

Sam Ottenhoff ottenhoff at longsight.com
Mon Jul 18 15:13:47 PDT 2011


Has anyone from U Delaware (original posters) tested the jQuery ui-block
patch I submitted?

jQuery is already included on all Samigo page loads. I would advocate for
relying on jQuery and a jQuery plugin instead of trying to maintain custom
JS.

--Sam

On Mon, Jul 18, 2011 at 5:54 PM, Charles Hedrick <hedrick at rutgers.edu>wrote:

> I've been playing with the javascript. It looks to me like an actual bug in
> Firefox. Mutual exclusion simply isn't working. THe code is
>
> disabled = false;
>
> onclick:
>   if (disabled == false) {
>       disabled = true;
>       disable other buttons;
>   } else {
>       disable this button
>   }
>
> The second branch doesn't happen. I did various tests and convinced myself
> that it is in fact doing the first branch twice.
>
> What the routines like disableNext do is disable all the *other* buttons.
> They can't disable next itself because then the form submission won't work.
> However at least with my copy of firefox hiding the button does work.
>
>   if (document.forms[0].elements['takeAssessmentForm:submitForm1'])
>
> document.forms[0].elements['takeAssessmentForm:submitForm1'].disabled=true;
>     if (document.forms[0].elements['takeAssessmentForm:submitForGrade'])
>
> document.forms[0].elements['takeAssessmentForm:submitForGrade'].disabled=true;
> >>>
>  document.forms[0].elements['takeAssessmentForm:next'].style.display='none';
>
> Hiding still keeps you from pushing it a second time, but allows the form
> submit to happen, which disable does not. I suggest some more testing, but
> that might be a reasonable workaround.
>
>
>
> On Jul 8, 2011, at 2:43 PM, Karen Tsao wrote:
>
> Hi Sam,
>
> Thanks a lot for coming up with a good solution on this issue. I will give
> it a try now.
>
> Thanks again,
> Karen
>
> On Thu, Jul 7, 2011 at 5:44 PM, Sam Ottenhoff <ottenhoff at longsight.com>wrote:
>
>> I just posted to the SAM-1244 JIRA. I tested using a simple jQuery
>> library called jQuery BlockUI (http://jquery.malsup.com/block/#page).
>>
>> I used one line of JS to initialize the blocking behavior:
>>
>>  $('input[type=submit]').click(function() { $.blockUI(); });
>>
>> I was no longer able to replicate the bug on Firefox 5.
>>
>> Does anyone have experience using this library? Any thoughts on
>> including it in /library/js/ instead of individual apps including it
>> separately? It is dual-licensed MIT and GPL.
>>
>> --Sam
>>
>>
>>
>> On 6/27/2011 4:00 PM, Mathieu Plourde wrote:
>> > BTW, we still don't have a fix for this, and we're getting more support
>> > requests from frustrated users.
>> >
>> > I think the issue is related to the way Firefox 4/5 handles javascript,
>> > so I'm cross-posting to the UX list.
>> >
>> > Mathieu
>> > ==================================
>> > Mathieu Plourde, MBA
>> > Project Leader, LMS/Educational Technologist
>> > IT Client Support & Services
>> > mathieu at udel.edu <mailto:mathieu at udel.edu>
>> > Office: 302-831-4060
>> > ==================================
>> > IT Support Center: http://www.udel.edu/help
>> > Sakai at UD Support and Training: http://www.udel.edu/sakai/training
>> >
>> >
>> >
>> > On Thu, Jun 23, 2011 at 10:46 AM, Mathieu Plourde <mathieu at udel.edu
>> > <mailto:mathieu at udel.edu>> wrote:
>> >
>> >     Hi dev list!
>> >
>> >     At Delaware, we have noticed this bug after our recent 2.8 upgrade.
>> >
>> >     https://jira.sakaiproject.org/browse/SAM-1244
>> >
>> >     "Rapidly clicking 'Next' or 'Previous' as a student taking a random
>> >     access test leads to validation errors and/or data discrepancy
>> >     errors in Firefox 4. We aren't able to reproduce this in IE or
>> >     Firefox 3.
>> >
>> >     It looks like the Javascript that disables the buttons until the
>> >     previous request is done isn't working in FF4
>> >
>> >     This is happening enough in our 2.8.0 production instance that it is
>> >     causing users to abandon Sakai for critical testing"
>> >
>> >     Despite their responsiveness, the Stanford team seems puzzled. We
>> >     were forced to recommend to our users to downgrade to Firefox 3. Who
>> >     else runs Sakai 2.8.0 in production right now? Anyone seen
>> >     differences in the way FF4 handles this?
>> >
>> >     Mathieu
>> >     ==================================
>> >     Mathieu Plourde, MBA
>> >     Project Leader, LMS/Educational Technologist
>> >     IT Client Support & Services
>> >     mathieu at udel.edu <mailto:mathieu at udel.edu>
>> >     Office: 302-831-4060
>> >     ==================================
>> >     IT Support Center: http://www.udel.edu/help
>> >     Sakai at UD Support and Training: http://www.udel.edu/sakai/training
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > sakai-dev mailing list
>> > sakai-dev at collab.sakaiproject.org
>> > http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>> >
>> > TO UNSUBSCRIBE: send email to
>> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
>> "unsubscribe"
>> _______________________________________________
>> sakai-dev mailing list
>> sakai-dev at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>
>> TO UNSUBSCRIBE: send email to
>> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
>> "unsubscribe"
>>
>
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to
> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
> "unsubscribe"
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20110718/9c6ca171/attachment.html 


More information about the sakai-dev mailing list