search

jfweemaes / ubiquity-xforms

Automatically exported from code.google.com/p/ubiquity-xforms
0 stars 0 forks source link

Many tests of relevancy and switch/case fail in Safari because of some strange delayed refresh weirdness #539

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago 
Test 6.1.4.a fails when run under Selenium in Safari. In both IE and Firefox, 
the same test passes when run under Selenium.

Original issue reported on code.google.com by phil.boo...@gtempaccount.com on 22 Sep 2009 at 2:31

GoogleCodeExporter commented 8 years ago

Original comment by phil.boo...@gtempaccount.com on 23 Sep 2009 at 11:38

GoogleCodeExporter commented 8 years ago 
I suspect that this is a CSS issue. MIPHandler.isEnabled() appears to behave 
sanely in 
this case under Safari 4 and, having now checked the CSS classes on the input 
elements, 
it looks like they've been correctly disabled.

Original comment by phil.boo...@gtempaccount.com on 24 Sep 2009 at 10:31

GoogleCodeExporter commented 8 years ago

Original comment by phil.boo...@gtempaccount.com on 25 Sep 2009 at 4:08

GoogleCodeExporter commented 8 years ago 
There is some weirdness surrounding this issue.

As I mentioned in a previous comment, everything in MIPHandler appears to occur 
correctly. Appropriate calls to UX.addClassName() are made to set the disabled 
class 
on the input elements. This class is correctly reflected in Safari 4's Web 
Inspector, 
yet the elements are still visible on the page.

This is where the weirdness starts. At this point, when the document has 
finished 
loading, if I do something like Edit > Preferences, it will sometimes cause the 
two 
disabled elements to suddenly hide themselves correctly. Invoking the Web 
Inspector 
instead at the same point also occassionally has the same effect.

Another time, I had the Web Inspector open while the disabled elements were 
still 
visible. According to the Web Inspector, they had the disabled class and were 
inheriting the visibility:hidden style as a result. Yet, clicking on the 
"Computed 
Style" tab revealed that the computed style was still visibility:visible. After 
some 
more playing around in the Web Inspector, the elements suddenly disappeared, a 
la the 
preceding paragraph, and when I once again checked the computed style, it had 
correctly updated to visibility:hidden on both input elements.

Now because of all this, and given that I've seen our code behave correctly in 
the 
debugger right up to the point we call YAHOO.util.Dom.addClass() in 
UX.addClassName(), I am feeling mildly suspicious of the YUI w.r.t. this issue.

I know, I know, blaming third party libraries and frameworks is the last 
recourse of 
the truly desperate, but it is where I'm currently at nonetheless. 
Unfortunately, the 
javascript debugger in Safari totally fails at stepping through the heavily 
obfuscated YUI code, so I've got nothing more concrete to offer than that at 
this 
point.

Original comment by phil.boo...@gtempaccount.com on 28 Sep 2009 at 11:00

GoogleCodeExporter commented 8 years ago 
Relinquishing this issue for a bit, while I seek out some quicker wins.

Original comment by phil.boo...@gtempaccount.com on 28 Sep 2009 at 11:21

GoogleCodeExporter commented 8 years ago 
I've raised issue 571 to investigate the weirdness that I describe in comment 
4, so I'm 
adding it as a blocker to this issue.

Original comment by phil.boo...@gtempaccount.com on 30 Sep 2009 at 12:35

GoogleCodeExporter commented 8 years ago 
Correction, the blocker is issue 574, not issue 571.

Original comment by phil.boo...@gtempaccount.com on 30 Sep 2009 at 12:35

GoogleCodeExporter commented 8 years ago

Original comment by phil.boo...@gtempaccount.com on 30 Sep 2009 at 1:40

GoogleCodeExporter commented 8 years ago 
I've closed off issue 574 as invalid and removed it as a blocker, because the 
other 
weirdness described by that issue has been addressed separately. So this issue 
stands 
alone now.

Original comment by phil.boo...@gtempaccount.com on 2 Oct 2009 at 9:25

GoogleCodeExporter commented 8 years ago 
A little more commentary on this issue.

Firstly, it appears to only be a problem in XHTML mode. HTML mode works 
correctly, 
which makes me less bothered about this issue as a showstopper for version 0.8 
/ 
Safari support.

Secondly, I thought it'd be instructive to try to reproduce the problem outside 
of 
UXF, but couldn't. It was just a little XHTML page, containing some javascript 
that 
added a class to a div element, causing said element to receive the visibility: 
hidden style. I tried calling the javascript code at various times, on load, 
after a 
five-second timeout, but the code worked as you'd expect every time. So it is 
definitely something in the UXF eco-system that is causing this.

Thirdly, on a whim, I decided to disable all of the pseudo-threadiness in UXF, 
just 
to see if that had any effect on the weird symptoms described in comment 4. No 
change.

Lastly, just to confirm, I have re-tested this with Erik's upgrade of the YUI 
to 
version 2.8. Sadly, no change there either.

Original comment by phil.boo...@gtempaccount.com on 15 Oct 2009 at 11:08

GoogleCodeExporter commented 8 years ago

Original comment by phil.boo...@gtempaccount.com on 21 Oct 2009 at 9:36

GoogleCodeExporter commented 8 years ago 
As I've found other Safari in the test suite that are covered by the weirdness 
discovered in this issue, I'm changing the title of this issue to be unspecific 
about 
test case 6.1.4.a and also listing the other test cases that suffer.

The full list of issues suffering from this Safari relevancy weirdness is:

6.1.4.a; 6.1.4.b; 6.1.4.c; 7.8.3.a; 7.8.3.b; 7.8.3.f; 7.8.4.a; 7.8.4.b; 7.8.4.f.

I may add others as I discover them.

Original comment by phil.boo...@gtempaccount.com on 21 Oct 2009 at 1:39

GoogleCodeExporter commented 8 years ago 
I've found some more tests that suffer from this same weirdness, and they're 
tests of 
switch and case, not relevancy. All of the other symptoms (like the delayed 
refresh 
occurring on seemingly unconnected events like invoking the web inspector) 
remain the 
same however. So I'm amending the issue title to incorporate switch and case. 
I'm 
also setting the priority to High, as all of these related tests make it a 
bigger 
deal.

Those extra tests in which I've witnessed the symptoms are:

9.1.1.a1; 9.2.1.a1; 9.2.1.a2; 9.2.2.a; 9.2.2.b; 9.2.2.c; 9.2.3.1.a; 9.2.3.1.b

Another interesting point to note is that there were some tests in this area of 
the 
test suite that don't exhibit the symptoms (e.g. 9.2.3.a). I shall investigate 
the 
differences present in that test to see if it shines any light on what is up.

Original comment by phil.boo...@gtempaccount.com on 21 Oct 2009 at 3:40

GoogleCodeExporter commented 8 years ago 
Removing redundancy from the issue title, the edit field was short enough that 
I didn't 
notice it just now.

Original comment by phil.boo...@gtempaccount.com on 21 Oct 2009 at 3:41

GoogleCodeExporter commented 8 years ago 
Also failing: 9.3.1.f & 9.3.4.a

Original comment by phil.boo...@gtempaccount.com on 21 Oct 2009 at 4:17

GoogleCodeExporter commented 8 years ago 
Another interesting case, where two of a set of three relating to switch/case 
demonstrate the symptoms of the problem, but the other one doesn't.

The failing tests: 10.6.1.a & 10.6.1.b

The passing test: 10.6.a

Original comment by phil.boo...@gtempaccount.com on 22 Oct 2009 at 9:04

GoogleCodeExporter commented 8 years ago 
Okay, I've been looking at the difference between 10.6.a and 10.6.1.a, 
described in the 
preceding comment. The crucial one seems to be the presence of messages in 
10.6.a. If I 
add equivalent XForms message elements to 10.6.1.a, the test works correctly. 
Visually 
it looks like the display of the messages is enough to force Safari to refresh 
the 
page, in the same way that Edit > Preferences or invoking the Web Inspector 
were 
observed to do in earlier comments.

Original comment by phil.boo...@gtempaccount.com on 30 Oct 2009 at 11:30

GoogleCodeExporter commented 8 years ago 
Based on the preceding comment, I was able to try out a hack of displaying and 
then 
immediately hiding a message window after the form has finished loading. This 
did have 
the effect of appearing to make the form load correctly. However, subsequent 
processing 
(e.g. when a switch is toggled to a different case) fails to work (e.g. old 
selected 
case does get hidden, but new selected case is never shown) and the above hack 
has no 
effect.

Original comment by phil.boo...@gtempaccount.com on 5 Nov 2009 at 12:35

GoogleCodeExporter commented 8 years ago 
Although the hack described above doesn't work for post-load refresh, the trick 
of 
invoking the Web Inspector does work (i.e. relevant/non-relevant controls are 
updated 
and cases are correctly toggled).

Original comment by phil.boo...@gtempaccount.com on 5 Nov 2009 at 12:56

GoogleCodeExporter commented 8 years ago 
Just wanted to make a note that I tried a recent WebKit nightly (r50541) on the 
off-
chance that it might magically fix this issue somehow, but it didn't.

Original comment by phil.boo...@gtempaccount.com on 11 Nov 2009 at 10:51

GoogleCodeExporter commented 8 years ago 
I've also tried using Safari 3.2.2 and that also exhibits this problem.

Original comment by phil.boo...@gtempaccount.com on 11 Nov 2009 at 12:52

GoogleCodeExporter commented 8 years ago 
I managed to pin-point this issue this afternoon and the apply a hack to fix 
it. 
Basically in XHTML mode in Safari we attempt to inject an "at-rule" ie 
@namespace i'm 
not sure if this is valid behaviour. I think we ignore it in FF and IE and 
Chrome is a 
little more robust and is able to recover by using the enabled property 
properly; I 
commented out the line 209 in UxUtils.js and Safari works as expected. I 
personally 
think that it is same to assume that the namespace declaration exists? If not 
then we 
need a way to add a namespace to the stylesheet?

Original comment by erik...@gmail.com on 28 Nov 2009 at 12:23

GoogleCodeExporter commented 8 years ago 
Excellent work identifying this, Erik. Unfortunately the fix doesn't seem to 
work for 
me. Are there any other changes in your working copy?

Also, on the question of whether we can assume the existence of the @namespace 
rule, I 
don't think we can. I reckon we'd need to find a way round the issue of adding 
it. But 
that's just me, others might think differently.

Original comment by phil.boo...@gtempaccount.com on 30 Nov 2009 at 10:29

GoogleCodeExporter commented 8 years ago 
There is a remote possibility that test cases 11.8.b and 11.8.c are also 
symptoms of 
whatever is causing this issue. Certainly they are Safari-specific and they 
rely on 
UX.addClassName (for the .header-ready class, in this case).

Original comment by phil.boo...@gtempaccount.com on 2 Dec 2009 at 12:04