Open GoogleCodeExporter opened 8 years ago
Original comment by phil.boo...@gtempaccount.com
on 23 Sep 2009 at 11:38
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
Original comment by phil.boo...@gtempaccount.com
on 25 Sep 2009 at 4:08
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
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
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
Correction, the blocker is issue 574, not issue 571.
Original comment by phil.boo...@gtempaccount.com
on 30 Sep 2009 at 12:35
Original comment by phil.boo...@gtempaccount.com
on 30 Sep 2009 at 1:40
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
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
Original comment by phil.boo...@gtempaccount.com
on 21 Oct 2009 at 9:36
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
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
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
Also failing: 9.3.1.f & 9.3.4.a
Original comment by phil.boo...@gtempaccount.com
on 21 Oct 2009 at 4:17
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
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
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
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
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
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
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
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
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
Original issue reported on code.google.com by
phil.boo...@gtempaccount.com
on 22 Sep 2009 at 2:31