I am cutting and pasting the reply I got from Microsoft today. They
definitely acknowledge it as a bug, but they seem to be implying it
is something that they may or may not fix. Please read over his reply
and give me any direction you can on how to proceed. I already
replied and told him that neither "workaround" he lists is valid for
us. Based on previous discussions, it sounds like roundcube intends
to maintain a real <a> tag pointing to a real URL.
Hi Joel,
The DIV case is really a different scenario. It does not have any
special meaning when Ctrl + Click so that should be consistent with
what you see in IE6. IE7 added a special case for Anchor tag
handling when Ctrl + Click. I am currently working on this issue
with my escalation engineer, Shahinur. You raise a valid point about
the onclick event should be fired for Ctrl + Click regardless of
which window the navigation happens in. At this point this does look
like a bug in IE7. I don’t see any good workaround for this
problem. There are a few ideas that that you may have already knew
or touched on at some point:
Try avoid using the Anchor tag, you can use other elements
like DIV (you already knew) or SPAN tag and still mimic the Anchor
tag appearance. Some thing like this:
<span style="text-decoration: underline; cursor:hand; color:blue" onclick="aFunction()" > click this "link" </span>.
It seems that if the Anchor tag does not have a valid href
URL attribute. If the href attribute is set to “” (empty string) or
“#” or even non-existant then things are working as expected. Below
is an example of the href missing:
If these workarounds do not work for you, we can request a hotfix
from the product team. Keep in mind that there is always a chance
that the hotfix request can be rejected. If you diecide to pursue
this route, I would need to have a Business Impact statement from you
addressing the following questions. Once I have the Business Impact
Statement, I can file a formal hotfix request to the product team:
- Business Impact - How does this bug affect your business - Why are current workarounds, if any, unacceptable
- Financial Impact (include how it was calculated) - What is the financial impact of the bug - What is the financial impact of the best
workaround, if any
3. Problem's frequency and probability?
4. Number of companies impacted
5. Number of corporate desktops and servers impacted
6. Number of consumer desktops (ie. home users) impacted
7. What IE platform is the hot fix needed?
- IE 6.0 sp2 on XP SP2
- IE 6.0 on Windows 2003 Server
- IE 6.0 on Windows 2003 Server SP1
- IE 7.0 on Vista
- IE 7.0 on XP SP2
- IE 7.0 on Windows 2003 Server SP1
9. What type of hot fix package do you need?
QFE – This package takes about 1-2 months to release
and has a strict acceptance criteria. It is only distributed to
customers by contacting Microsoft Support referencing a KB article.
It is also redistributable only within a corporation (but not to the
corporation’s customers). The fix is usually enabled by setting a
specific registry key on the machine.
GDR – This package takes about 3-6 months to release
and is subjected to more testing and an even higher acceptance
criteria. It is distributed to customers by downloading it from a
public Microsoft link. This package is normally not available if a
QFE meets your needs.
8. What languages (English, Chineses,...) are needed?
Joel Clermont joel@orionweb.net 262-377-9930
List info: http://lists.roundcube.net/dev/
On Friday 21 September 2007, Joel Clermont wrote:
If these workarounds do not work for you, we can request a hotfix from the product team. Keep in mind that there is always a chance that the hotfix request can be rejected. If you diecide to pursue this route, I would need to have a Business Impact statement from you addressing the following questions. Once I have the Business Impact Statement, I can file a formal hotfix request to the product team:
<we'll only fix this if you are important enough>
I can't believe this! You've proven to them it's a nonstandard behaviour, it breaks actions that are expected, they even admitted it's a _bug_, and they tell you to get down on your knees and beg so they _might_ fix it, but only if they deem you important enough, _and_ there's enough money involved!
How much would I like to put a fat notice on the roundcube homepage saying "IE7 broken!", we don't support it period.
What a bunch of arrogant, superbureaocratic, incapable assholes!
Sorry, I had to let this steam off ;)
~Mik
I had a long talk with this support rep on the phone the other day.
He said that a number of people (though he wouldn't tell me how many)
have filed a bug notice on this very issue. Internally, the bug is
graded as "fix in next release", which means IE 8. That is probably
at least 3 years off, and likely longer. He said that no one has yet
opened a formal support ticket on this issue. We are the first. It's
a shame we have to play their game, but the only way to get your
bug's priority bumped is to make a business impact case. Then again,
there is no guarantee that they will escalate the bug even with this
document. And even if they do escalate it, the best case time frame
for a generally deployed fix is 3 - 6 months. Despite this, I think
it is still worth submitting the document and getting the process
started.
In the meantime, I wanted to propose an alternate solution. As I
understand it, making the subject text an <A> tag was to accommodate
a small subset of users. Could we possibly create a new setting in
the personal settings area where the individual user could toggle
whether they want this as an <A> tag or not? Ideally, the server
admin could set a default value and then let users override it. I
think this might be the best short term solution until MS fixes the
real bug, if they ever do.
What does everyone think? Also, could someone take a few minutes and
explain to me again the full reason for the <A> tag with a real href?
Was it just accessibility reasons?
Joel Clermont joel@orionweb.net 262-377-9930
On Sep 22, 2007, at 5:50 AM, Michael Büker wrote:
On Friday 21 September 2007, Joel Clermont wrote:
If these workarounds do not work for you, we can request a hotfix from the product team. Keep in mind that there is always a chance that the hotfix request can be rejected. If you diecide to pursue this route, I would need to have a Business Impact statement from you addressing the following questions. Once I have the Business Impact Statement, I can file a formal hotfix request to the product team:
<we'll only fix this if you are important enough>
I can't believe this! You've proven to them it's a nonstandard
behaviour, it breaks actions that are expected, they even admitted it's a _bug_,
and they tell you to get down on your knees and beg so they _might_ fix it,
but only if they deem you important enough, _and_ there's enough money
involved!How much would I like to put a fat notice on the roundcube homepage saying "IE7 broken!", we don't support it period.
What a bunch of arrogant, superbureaocratic, incapable assholes!
Sorry, I had to let this steam off ;)
~Mik
-- Heisenberg gets stopped by a cop for speeding. "Do you have any idea how fast you were going?", asks the cop. "No. But I know exactly where I am!" _______________________________________________ List info: http://lists.roundcube.net/dev/
List info: http://lists.roundcube.net/dev/
On 9/21/07, Joel Clermont joel@orionweb.net wrote:
(...)
Try avoid using the Anchor tag, you can use other elements like DIV(you already knew) or SPAN tag and still mimic the Anchor tag appearance. Some thing like this:
<span style="text-decoration: underline; cursor:hand; color:blue" onclick="aFunction()" > click this "link" </span>.
He raises a valid point.There are plenty other reasons to use <span> instead of <a>: http://xkr.us/js/links http://tom.me.uk/scripting/links.html
Till _______________________________________________ List info: http://lists.roundcube.net/dev/
I thought the point of making our subject line an <A> tag was not
just for the "appearance" of a link, but to provide a valid link for
accessibility reasons. Is my understanding correct? Or is there a
different reason why the <A> tag was chosen?
Joel Clermont joel@orionweb.net 262-377-9930
On Sep 22, 2007, at 11:01 AM, till wrote:
On 9/21/07, Joel Clermont joel@orionweb.net wrote:
(...)
Try avoid using the Anchor tag, you can use otherelements like DIV (you already knew) or SPAN tag and still mimic the Anchor tag
appearance. Some thing like this:<span style="text-decoration: underline; cursor:hand; color:blue" onclick="aFunction()" > click this "link" </span>.
He raises a valid point.There are plenty other reasons to use <span> instead of <a>: http://xkr.us/js/links http://tom.me.uk/scripting/links.html
Till
List info: http://lists.roundcube.net/dev/
On 9/22/07, Joel Clermont joel@orionweb.net wrote:
I thought the point of making our subject line an <A> tag was not just for the "appearance" of a link, but to provide a valid link for accessibility reasons. Is my understanding correct? Or is there a different reason why the <A> tag was chosen?
No, you are probably correct. ;-) A <span> tag would not make it accessable when JavaScript is deactivated.
Till _______________________________________________ List info: http://lists.roundcube.net/dev/
On Sat, 22 Sep 2007 14:45:22 +0200, Joel Clermont joel@orionweb.net
wrote:
What does everyone think? Also, could someone take a few minutes and
explain to me again the full reason for the <A> tag with a real href?
Was it just accessibility reasons?
Hi,
"*just* accessibility" does not exist ;o)
Accessibility is not about blind grandmas using an old 386 with braille
keyboard, it is about an application being easy to use for us all,
regardless of the device we are using, the device ranges from a PDA,
iPhone, PS2 to a thin client in a corporate network that doesn't allow
modifyinf strict securoity settings or remote ssh access to a computer
that only allows using a text-based browser like Lynx, up to ease of use
for regular users too.
I haven't followed this bug from the beginning, so I'm not sure exactly
what is affected, but if it is the title of the email that you click to
read the mail, having it as an <a>-tag also allows one to click it with
the middle mouse-button to open that email in a new browser-tab, so
multiple emails can be opened together, it allows bookmarking emails, it
allows saving the email locally and the back-button might work for paging
between emails - of course this bug might be regarding a different
<a>-tag, so I might be way off-base here.
Regarding a fix for the problem:
Have you tried replacing the 'onclick' event with an 'onmouseup' event?
Personally I always use onmouseup anyway, as it better mirrors the way an
OS works, where you can click something, and if you see you are on the
wrong button you can move your mouse to the correct button and release it
there without fireing the first one.
Another solution might be to detect the exact version of IE that has this
problem, and then do a DOM-replacement replacing the <a> by a <span> only
for that browser-version - this would leave all other browser alone, as
well as people using that browser-version without javascript.
Hope all that helps in some way...
Richard. _______________________________________________ List info: http://lists.roundcube.net/dev/
Hi, "*just* accessibility" does not exist ;o)
I wasn't using the word "just" to imply importance here. I used it in
the sense of "quantity". I value accessibility very highly myself.
Accessibility is not about blind grandmas using an old 386 with
braille keyboard, it is about an application being easy to use for us all, regardless of the device we are using, the device ranges from a PDA, iPhone, PS2 to a thin client in a corporate network that doesn't allow modifyinf strict securoity settings or remote ssh access to a computer that only allows using a text-based browser like Lynx, up to ease
of use for regular users too.
Funny that you should mention the iPhone, since there is no way at
all to open an email message in Round Cube on an iPhone, but I
digress . . . .
I haven't followed this bug from the beginning, so I'm not sure
exactly what is affected, but if it is the title of the email that you
click to read the mail, having it as an <a>-tag also allows one to click it
with the middle mouse-button to open that email in a new browser-tab
Actually, the click event gets cancelled if javascript is enabled, so
having the subject text be an <A> tag here does not allow special
behaviors for opening in new windows/tabs. In fact, it is the ctrl-
click in IE 7 for "open in new tab" that is the very source of this
problem and the whole reason we are discussing it. If IE7 didn't have
this bug, you would not be able to open this in a new tab. Remember
it is a double click that opens a message in Round Cube. There is no
other way to open it.
, so multiple emails can be opened together, it allows bookmarking
emails, it allows saving the email locally and the back-button might work for
paging between emails - of course this bug might be regarding a different <a>-tag, so I might be way off-base here.
I think you have a valid point with bookmarking. If we didn't have
the real URL in the A tag in the message list, you could not bookmark
from that page, though you could once you opened the message of course.
Regarding a fix for the problem: Have you tried replacing the 'onclick' event with an 'onmouseup'
event?
Now this is pure genius! It WORKS! Test it out on http://orionweb.net/
joelstuff/click.html I had to capture both onclick and onmouseup
because for some reason in Safari cancelling onmouseup did not cancel
the click. I didn't do much testing though so maybe i am missing
something. What does everyone think? Is this a workable solution?
onmouseup has some quirks. For example, if you start a click
somewhere else, hold the button, then move the mouse above the link
and release it, mouseup fires for the object you are under, not the
one you originally clicked. Personally, I think I could live with
that though.
This is exciting :-)
Personally I always use onmouseup anyway, as it better mirrors the
way an OS works, where you can click something, and if you see you are on the wrong button you can move your mouse to the correct button and
release it there without fireing the first one. Another solution might be to detect the exact version of IE that
has this problem, and then do a DOM-replacement replacing the <a> by a
<span> only for that browser-version - this would leave all other browser
alone, as well as people using that browser-version without javascript.
Unfortunately, IE7 is fast eclipsing IE6 and will soon be the
dominant browser for years to come. If we disable <a> tags in IE7, we
are breaking accessibility for a very large audience. I wish it
wasn't true, but this is life.
Hope all that helps in some way...
It helped immensely. Thank you!
Richard. _______________________________________________ List info: http://lists.roundcube.net/dev/
Joel Clermont joel@orionweb.net 262-377-9930
List info: http://lists.roundcube.net/dev/
till wrote:
On 9/22/07, Joel Clermont joel@orionweb.net wrote:
I thought the point of making our subject line an <A> tag was not just for the "appearance" of a link, but to provide a valid link for accessibility reasons. Is my understanding correct? Or is there a different reason why the <A> tag was chosen?
No, you are probably correct. ;-) A <span> tag would not make it accessable when JavaScript is deactivated.
Well, RoundCube isn't actually designed to work without javascript. The subject link was requested by some users and it provides the possibility to right-click the subject and then choose "Open in new Tab/Window". In this case (right-click), the regular click-event is not executed and everything works fine (until IE7 came out).
Thanks again for tracking this down, I'll try out the onmouseup workaround. And once more M$ confirmed that money always wins.
~Thomas _______________________________________________ List info: http://lists.roundcube.net/dev/
Thank you Thomas. Let me know if I can be of any further assistance
on this issue.
Joel Clermont joel@orionweb.net 262-377-9930
On Sep 24, 2007, at 2:35 AM, Thomas Bruederli wrote:
till wrote:
On 9/22/07, Joel Clermont joel@orionweb.net wrote:
I thought the point of making our subject line an <A> tag was
not just for the "appearance" of a link, but to provide a valid link for
accessibility reasons. Is my understanding correct? Or is there a different
reason why the <A> tag was chosen?No, you are probably correct. ;-) A <span> tag would not make it accessable when JavaScript is deactivated.
Well, RoundCube isn't actually designed to work without javascript.
The subject link was requested by some users and it provides the
possibility to right-click the subject and then choose "Open in new Tab/Window".
In this case (right-click), the regular click-event is not executed and
everything works fine (until IE7 came out).Thanks again for tracking this down, I'll try out the onmouseup
workaround. And once more M$ confirmed that money always wins.~Thomas _______________________________________________ List info: http://lists.roundcube.net/dev/
List info: http://lists.roundcube.net/dev/
Joel Clermont wrote:
Thank you Thomas. Let me know if I can be of any further assistance on this issue.
Joel Clermont joel@orionweb.net mailto:joel@orionweb.net 262-377-9930
On Sep 24, 2007, at 2:35 AM, Thomas Bruederli wrote:
till wrote:
On 9/22/07, Joel Clermont <joel@orionweb.net mailto:joel@orionweb.net> wrote:
I thought the point of making our subject line an <A> tag was not just for the "appearance" of a link, but to provide a valid link for accessibility reasons. Is my understanding correct? Or is there a different reason why the <A> tag was chosen?
No, you are probably correct. ;-) A <span> tag would not make it accessable when JavaScript is deactivated.
Well, RoundCube isn't actually designed to work without javascript. The subject link was requested by some users and it provides the possibility to right-click the subject and then choose "Open in new Tab/Window". In this case (right-click), the regular click-event is not executed and everything works fine (until IE7 came out).
Thanks again for tracking this down, I'll try out the onmouseup workaround. And once more M$ confirmed that money always wins.
And one more reason for users to switch to FireFox. :)
Rich _______________________________________________ List info: http://lists.roundcube.net/dev/
-
Joel Clermont -
Michael Büker -
Rich at Whidbey Telecom -
Richard Bennett -
Thomas Bruederli -
till