<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: I Hate Accesskeys</title>
	<atom:link href="http://www.yetanothertechblog.com/2009/06/17/i-hate-accesskeys/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.yetanothertechblog.com/2009/06/17/i-hate-accesskeys/</link>
	<description>Just another WordPress weblog</description>
	<lastBuildDate>Sat, 06 Mar 2010 13:54:55 +0100</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Neil Rashbrook</title>
		<link>http://www.yetanothertechblog.com/2009/06/17/i-hate-accesskeys/comment-page-1/#comment-3160</link>
		<dc:creator>Neil Rashbrook</dc:creator>
		<pubDate>Fri, 19 Jun 2009 08:34:59 +0000</pubDate>
		<guid isPermaLink="false">http://www.yetanothertechblog.com/?p=44#comment-3160</guid>
		<description>Axel: Access keys in different panes shouldn&#039;t conflict - I fixed this bug specifically to make it possible to switch SeaMonkey over to using the toolkit preferences system.

Dolske: Yes, the main context menu is a veritable pain - SeaMonkey has quite a largish context menu (even without a separate Copy Image Location menuitem) and so far we haven&#039;t worked out how to assign access keys without conflicts :-(</description>
		<content:encoded><![CDATA[<p>Axel: Access keys in different panes shouldn&#8217;t conflict &#8211; I fixed this bug specifically to make it possible to switch SeaMonkey over to using the toolkit preferences system.</p>
<p>Dolske: Yes, the main context menu is a veritable pain &#8211; SeaMonkey has quite a largish context menu (even without a separate Copy Image Location menuitem) and so far we haven&#8217;t worked out how to assign access keys without conflicts <img src='http://www.yetanothertechblog.com/wp-includes/images/smilies/icon_sad.gif' alt=':-(' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Wladimir Palant</title>
		<link>http://www.yetanothertechblog.com/2009/06/17/i-hate-accesskeys/comment-page-1/#comment-3158</link>
		<dc:creator>Wladimir Palant</dc:creator>
		<pubDate>Fri, 19 Jun 2009 06:39:44 +0000</pubDate>
		<guid isPermaLink="false">http://www.yetanothertechblog.com/?p=44#comment-3158</guid>
		<description>I feel your pain, I started using automated access key checks for Adblock Plus a while ago - and felt an immediate relief. Access key conflicts are still responsible for the larger part of my communication with localizers. But at least the complicated manual testing is no longer required.

I didn&#039;t design any generic solution of course, simply listed the groups of access keys that are found in the same context. Testing for access keys that cannot be found in the label is easier thanks to consistent naming of DTD values. Sadly, neither approach will work on the scale of the Firefox project.</description>
		<content:encoded><![CDATA[<p>I feel your pain, I started using automated access key checks for Adblock Plus a while ago &#8211; and felt an immediate relief. Access key conflicts are still responsible for the larger part of my communication with localizers. But at least the complicated manual testing is no longer required.</p>
<p>I didn&#8217;t design any generic solution of course, simply listed the groups of access keys that are found in the same context. Testing for access keys that cannot be found in the label is easier thanks to consistent naming of DTD values. Sadly, neither approach will work on the scale of the Firefox project.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Justin Dolske</title>
		<link>http://www.yetanothertechblog.com/2009/06/17/i-hate-accesskeys/comment-page-1/#comment-3155</link>
		<dc:creator>Justin Dolske</dc:creator>
		<pubDate>Wed, 17 Jun 2009 16:59:38 +0000</pubDate>
		<guid isPermaLink="false">http://www.yetanothertechblog.com/?p=44#comment-3155</guid>
		<description>I added tests for the content area content menu, though it&#039;s obviously only testing en-US. See browser/base/content/test/test_contextmenu.html

This is a particularly fun case, because the menu content depends on what you&#039;re right-clicking on and sometimes other state (eg, if an image has finished loadded, or if something is selected).</description>
		<content:encoded><![CDATA[<p>I added tests for the content area content menu, though it&#8217;s obviously only testing en-US. See browser/base/content/test/test_contextmenu.html</p>
<p>This is a particularly fun case, because the menu content depends on what you&#8217;re right-clicking on and sometimes other state (eg, if an image has finished loadded, or if something is selected).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Axel Hecht</title>
		<link>http://www.yetanothertechblog.com/2009/06/17/i-hate-accesskeys/comment-page-1/#comment-3151</link>
		<dc:creator>Axel Hecht</dc:creator>
		<pubDate>Wed, 17 Jun 2009 09:56:03 +0000</pubDate>
		<guid isPermaLink="false">http://www.yetanothertechblog.com/?p=44#comment-3151</guid>
		<description>I have a checker for accesskeys in my coverage extension (which I haven&#039;t been running for a while). But that only covers the menu bar and the preference dialog plus a few more. Which reminds me that the preference dialog is the worst piece, as you actually get different conflicts depending on which panes you look at in which order. All loaded overlays for the pref panes contribute the access key context, but the panes only load once you select them.

So, open pref dialog on General, go to Advanced, get an accesskey conflict. Close dialog and open it again, it opens with just Advanced, and no conflict. Fun, huh? (And known xul bug.)

Your quest for checking the context menus on different selections sounds like a great case for writing a mozmill test. I&#039;m hoping that we&#039;ll get l10n runtime tests based on that. Clint works on the build integration per se in bug 457265.</description>
		<content:encoded><![CDATA[<p>I have a checker for accesskeys in my coverage extension (which I haven&#8217;t been running for a while). But that only covers the menu bar and the preference dialog plus a few more. Which reminds me that the preference dialog is the worst piece, as you actually get different conflicts depending on which panes you look at in which order. All loaded overlays for the pref panes contribute the access key context, but the panes only load once you select them.</p>
<p>So, open pref dialog on General, go to Advanced, get an accesskey conflict. Close dialog and open it again, it opens with just Advanced, and no conflict. Fun, huh? (And known xul bug.)</p>
<p>Your quest for checking the context menus on different selections sounds like a great case for writing a mozmill test. I&#8217;m hoping that we&#8217;ll get l10n runtime tests based on that. Clint works on the build integration per se in bug 457265.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
