Ben Bucksch (:BenB) Reporter
	Description • 24 years ago

Reproduction:
1. visit <http://freshmeat.net/projects/gnoise/>
2. Right-click on screenshot to open context menu.

Actual result:
Window and context menu opens

Expected result:
Only context menu opens

Additional comments:
- If I do a right-click, I intentionally didn't mean to do a normal click.
- Can also be seen on the advertizing table background at the Google result
pages. Right-click on the green area (e.g. to go "Back").
- Highly irritating. Very visible.

	Boris Zbarsky [:bzbarsky]
	Comment 1 • 24 years ago

Over to event handling

	Ben Bucksch (:BenB) Reporter
	Comment 2 • 24 years ago

I think, I saw this in 0.6 already.

	Loco
	Comment 3 • 24 years ago

I hesitate to mark it as a duplicate of bug 30881, since it was fixed at one
point or another.  Perhaps marking it as a duplicate and reopening the original
wouldn't be a bad idea.

	Loco
	Comment 4 • 24 years ago

Might also be related to bug 63073.  FWIW, th emore I think about it, the more I
think this should be marked as a duplicate of bug 30881, with the original reopened.

	Blake Ross
	Comment 5 • 24 years ago

Right click is supposed to fire onclick. What's the issue?

	Ben Bucksch (:BenB) Reporter
	Comment 6 • 24 years ago

Says who? The HTML 4 specs just says "The onclick event occurs when the pointing
device button is clicked over an element.". If I say "Click on button Stop", do
you right-click? Since there is no onlelftclick helandler or similar, I can only
assume, the author of the spec meant the ordinary left-click (primary mouse
button click, to be precise).

Anyway, I don't want any untrusted script to ever override right-click. This is
sometimes used to obfuscate the source (disable menu and right-click). Please
give me in any case the option to disallow that.

	Ben Bucksch (:BenB) Reporter
	Comment 7 • 24 years ago

> What's the issue?

To answer this without ambiguity: See reproduction. The result is obviously not
what I, the user, expected. And this is true in almost all cases. Why *should*
it trigger onclick? leftclick != rightclick.

	Blake Ross
	Comment 8 • 24 years ago

Left click != right click, sure, but that doesn't mean onclick == left click 
necessarily...If it didn't specify it, we'd still want to include right and 
middle clicks, since there's no real reason to assume any button.  But that's 
not an issue, since DOM2 *does* pretty much specify it; mouse events have a 
button property which is equal to an integer that corresponds to each mouse 
button.  Read up at http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-
eventgroupings-mouseevents.

I agree that if we keep right click firing onclick (it seems that IE doesn't), 
there should be a way to disable it for annoying websites.

	sairuh (rarely reading bugmail)
	Comment 9 • 24 years ago

methinks this bug won't get fixed for 0.8. renominating.

	Loco
	Comment 10 • 24 years ago

just my $0.00000002M...

If you read most software manuals, you will probably see references to clicking
and right-clicking (yeah, like anyone here ever read a manual:)).  To some
extent, at least, clicking *does* mean left-clicking simply by convention-it's
implied.

DOM2, blah, blah, when Mozilla has support for it, we can come back to this
argument, but for now the right click has a function, and it is a contextual
menu.  Having it also trigger an onClick for any reason interrupts its primary
function, and is thus undesirable-at least for now.

	Blake Ross
	Comment 11 • 24 years ago

> DOM2, blah, blah, when Mozilla has support for it, we can come back to this
> argument

This seems like a Catch-22.  How can Mozilla support DOM2 if it doesn't follow 
the language's spec?

	joki (gone) Assignee
	Comment 12 • 24 years ago

I'm not going to mark this as a dupe of 28604 but I will mark it related to it.  
The hard fact is that the web page is wrong from DOM 2 standards.  We've been 
discussing how to deal with this for compatibility with older pages.  We think 
we might tie into the 'quirks' mode setting which we use for older pages.  We 
may still do that but unfortunately for this page they are using up to date DTD 
links so they are defining themselves to be up to date.  'quirks' mode would 
therefore be turned off.

I'm happy to keep this bug open to discuss possible alternatives for dealing 
with this but I'm moving the milestone out.  Also replaced the 'regression' 
keyword with '4xp' which is more appropriate to the bug since mozilla has always 
worked like this so its not a regression.

	Ben Bucksch (:BenB) Reporter
	Comment 13 • 24 years ago

> The hard fact is that the web page is wrong from DOM 2 standards

I don't know the DOM2 spec, but from the HTML spec, the page is completely OK. I
argue that "click" = left-click, if nothing suggests the opposite.

> I'm happy to keep this bug open to discuss possible alternatives for dealing
> with this

Why can't you just treat HTML's "onclick=" as meaning left-click only? Does the
DOM2 spec conflict with this in a non-resolveable way?

Again, in *any* case, give an option to disable that. Webpages should *not* (not
even with DOM2) be allowed to change right-click, because I need it to access
the context menu. Overriding this completely cripples my ability to use the browser.
I cannot tell you what to work on, but this isn't something to Future, IMO. At
least not the pref I described.

	Ben Bucksch (:BenB) Reporter
	Comment 14 • 24 years ago

One example, where this bug matters: I want to copy the URL of a link, but I do
not want to visit it, beacuse I don't want to leave trails in the server logs or
whatever reason. I right-click on the link to access "Copy Link Localtion". The
link has an onclick handler (unfortunately *very* common together with
window.open). onclick triggers, the window opens, the page loads. Bummer,
privacy violation.

	Phil Schwartau
	Comment 15 • 24 years ago

*** Bug 73172 has been marked as a duplicate of this bug. ***

	Jacob Kjome
	Comment 16 • 24 years ago

A while ago on one of the w3c email list archives, I was following a discussion
about how to deal with the fact that the attribute "target" has been depricated
for all but the frameset dtd's.

What many people did if they wanted links on their page to open in a new window
was to put: 
<a href="somepage.html" target="_blank">.  

The argument against the target attribute for anything other than frames was
that it forced the link to open in a new window with no recourse for the user. 
It also provided no information about the content within the a tag.  The
solution that was finally agreed upon was doing something like: 
<a href="sompage.html" onclick="newWin(this.href); return false;">

where newWin() contains a window.open syntax

The argument for this is that new windows should be scripted rather than be part
of the html spec AND a user can diable the new window by by simply turning
javascript off.  It is also much better than the other scripting alternative:
<a href="javascript:newWin(somepage.html);">

because the link is dead unless a user turns on javascript where, in the onclick
example, the link is still visitable even with javascript turned off.

Now to how the above relates to this bug...

When I use this script, my intention is to open the link in a new window when
the link is LEFT clicked (just like you would go to any normal link).  However,
if I don't want to follow the link, but rather just copy it or bookmark that
specific link, it becomes impossible if the onclick is triggered on a RIGHT click.

I use this extensively on the following page:

http://www.visi.com/~hoju/humor.html

Now, you can make the argument that I shouldn't do this in the first place, but
who are you to judge my intentions (and vice versa).  Please just accept the
fact that I do it...and, btw, you may also notice the the page is HTML 4.01
STRICT and CSS compliant.

I can see the argument that the onclick handler should catch any click and then
we should check in javscript which button it was... and I may very well do that
as a workaround, but you still have the problem with user and developer
expectation where onclick (implicitly) means LEFT click.

If you attempt to solve this with the whole quirks-vs-standards modes, that
really doesn't get to the issue because it deals much more with layout than with
javascript (let me know if my assumption is incorrect here).

I'm really starting to see Blake's DOM2 support argument the more I write...but,
at the same time, I know it will break a ton of scripts out there currently.

In the meantime, I will be updating my script to check for which mouse button
was clicked and do nothing on a RIGHT click.

hmmmm...???????

Jake

	Ben Bucksch (:BenB) Reporter
	Comment 17 • 24 years ago

> <a href="somepage.html" target="_blank">.  
> The argument against the target attribute for anything other than frames was
> that it forced the link to open in a new window with no recourse for the user.

Who said that? Do you have a reference? Because I strongly disagree, but it's
not the topic of this bug.

	Jesse Ruderman
	Comment 18 • 24 years ago

See also bug 72084, "There is no way to disable the context menu upon right-
click".

	Taras Tielkes
	Comment 19 • 24 years ago

Bug 28604 is about the need to disable the context menu. This is useful in some 
special cases. In most cases this is for specific elements. Anyway, that need 
is addressed by the "oncontextmenu" event.

This bug is more important, IMO. Classis browsers always fired the "click" 
event for a left-button press. It seems that the DOM2+ specs suggest 
(not "imply" IIRC - button information is 'accesable' from mouse event 
handlers) that every click, left, middle or right, fires the "onclick" event.

My suggestion:
1) Make "onclick" only work for LMB clicks (or whatever equivalent on other 
platforms).
2) Make the other mouseclick events (mousedown + mouseup) work on all button 
clicks. That way, the functionality is still there if desired.
3) Suggest this change to the DOM spec.

	Dylan Schiemann
	Comment 20 • 24 years ago

I think the spec. makes it pretty clear and it makes sense when you consider
that the Mac has only one click button and linux supports three buttons.  When
you have an onclick event, you should check button attribute to see which button
was clicked (0 left, 1 middle, 2 right).  This is a nice, clean, generic,
cross-platform solution except for the case of the occasional annoying site
which wants to disable your right to right click on some aspect of their site.

using event.preventDefault() for onclick with event.button == 2 would in theory
cancel the contextmenu.

As I said on n.p.m.dom ng, I think that ideally you need to give the user the
right to keep their contextmenu, but also the author the right to let them know
that they are missing out if the user chooses to disable it.

repost from ng: "I would think that the user should have the following
choices:

1) accept authors context menus
2) combine authors context menu with mozilla context
menu
3) accept only mozilla context menus

I would also think that if someone is operating in the
third mode, there should be a way for the author to
let them know that they are "missing out" on the
feature, i.e. some way for the author to see if
oncontextmenu has been disabled and encourage them to
enable it for that site only."

A major problem is that many things are coarse grained... in the past the only
choice was to disable scripts.  We need to give the user choices for the most
obviously intrusive abuses (spawning new windows, disabling context menus,
taking away chrome, keeping focus, etc.), but we also need to give the author
the right to know how their page is being viewed, what options the user is
permitting them to use, etc.

If a particular web app would not be easy to implement withouth a context menu,
the author has the right to tell the user that the web app is severely limited
because they have disabled that feature.  Without compromising user security.

	Ben Bucksch (:BenB) Reporter
	Comment 21 • 24 years ago

Dylan, let's discuss this on the newsgroup. My reply there.

	Jacob Kjome
	Comment 22 • 24 years ago

I found an example on webreview.com where what I expect upon a right click of a 
particular link is Mozilla's context menu.  However, what happens is a new 
window gets popped up and I don't see any context menu.  To see it in action, 
go here:  http://www.webreview.com/style/   and click on the "Browser 
Compatibility Chart Key" link (near the middle of the page).

here's the "offending" code:

<a href="/style/key.shtml" onClick="window.open
('/style/key.shtml','key','toolbar=no,width=400,height=400,status=no,location=no
,scrollbars=yes,resize=yes,menubar=yes');return false"><b>Browser Compatibility 
Chart Key</b></a>

Now this isn't just "spawning new window" in a bad sense; this window is 
supposed to be small and suppposed to be there as a reference key for other 
pages.

Now, this example is almost exactly like what I described in my previous post.  
What I *should* be able to do is Left click to follow the link (or pop up a new 
window... whatever the author intended to happen) OR Right click and get a 
context menu that would allow me to do one of a number of things like; copy the 
link location, bookmark the link, open the link in a new window, save link 
as..., Edit link in composer, etc...

Like I argued earlier, using the onclick to open a window rather than 
target="_blank" both provides conformance to the strict DTD's AND, more 
importantly, provides a way for the author to provide some intended 
functionality while respecting the user's preference about what to do with the 
link.  Keep in mind, the other alternative, href="javascript:window.open(...)", 
both breaks the link for users who disable javascript and provides no recourse 
for the user who has javascript enabled. Plus, even with javscript enabled, the 
link isn't really bookmarkable!

The problem is (barring a massive evangelism campaign on letting developers 
know that they should check which mouse button was clicked before running their 
code) that Mozilla will break scripts like this and, along with that, developer 
and user flexibility.

Is there truly no solution to comply with the spec AND default OnClick to the 
main mouse button (usually left on Windows)???  If a solution could be created, 
it would keep Mozilla from being that "bastard browser that keeps breaking my 
scripts", but rather that "cool new browser that my existing scripts still work 
with".

Jake

	Blake Ross
	Comment 23 • 24 years ago

This is really a UI design issue at this stage.  Do we want to go against the 
spec?  Sending to UI Design for feedback.

	Ben Bucksch (:BenB) Reporter
	Comment 24 • 24 years ago

> Do we want to go against the spec?

blake, as I said, the HTML spec is not clear here. Common interpretation is
"left click only". And the DOM2 spec does not matter, when you are rendering
documents that were written before the DOM2 spec existed. So, please don't say
that this behaviour were against "the spec".

	Matthew T (active 1999-2002)
	Comment 25 • 24 years ago

This is simple from a usability standpoint. Remote content should never be able 
to respond to, or interfere with my use of, a secondary mouse button. Not ever. 
To do so would allow malicious Web authors to reduce Mozilla's usefulness,
and/or to restrict users' ability to use (or link to) the author's content.

The main thing this would achieve would be to force users to switch to a 
browser other than Mozilla, a browser which didn't allow remote content to do 
these things. So if the DOM spec says this, or any other spec present or 
future, the spec will be proven wrong by user force.

Back to Event Handling.

	Nisheeth Ranjan
	Comment 26 • 24 years ago

Moving back to the 0.9.2 milestone. Tom, as we decided on the phone, lets
re-examine this bug and figure out what to do here. Currently, the click
handlers get fired for right clicks on anchors but not for right clicks on
buttons. That seems inconsistent and should be addressed.

Some ideas you mentioned during our phone conversation were

a) to support backwards compatible behavior via quirks mode code
b) to implement the Activate event as prescribed by the Accessibility WG

	Keyser Sose
	Comment 27 • 24 years ago

*** Bug 81610 has been marked as a duplicate of this bug. ***

	Edwin Aoki
	Comment 28 • 24 years ago

I strongly disagree with the statement that "Remote content should never be able 
to respond to, or interfere with my use of, a secondary mouse button. Not ever."  
Witness the case of many web applications - surveys, HR forms, stock trading, 
etc." which have in big bold type at the top of the page "Do not use your 
browser's back button for doing so will cause [multiple data submissions/lost 
data/general havoc]".  If I'm a developer which is trying to use Mozilla as a 
platform to deliver application-like content, and I want to provide other 
semantics on the right mouse button or explicitly prevent the contextual menu 
from popping up, I should be able to do so.  This is explicitly required for 
compatibility.

Witness Netscape's own Javascript 1.3 spec 
(http://developer.netscape.com/docs/manuals/js/client/jsref/handlers.htm#1119876
)  There, the onClick event is spec'ed to take an event parameter which, among 
other things specifies the "which" field, which specifies the button number 
pressed.  If onClick stops being fired for right mouse buttons, any older 
Javascript which takes action only on the right mouse button will now stop 
working.

So the most "right" way to handle this case would be to allow onClick to fire 
for all buttons and for developers who are interested in a particular mouse 
button to explicitly trap that mouse button for a particular behavior.  I 
suppose the most compatible compromise would be that for inline scripts with no 
arguments (of the form onClick="Do something interesting") that the default 
behavior should be not to fire for buttons other than the default; in practice, 
though, this strikes me as really, really ugly - and may not be workable in any 
case.

	Ben Bucksch (:BenB) Reporter
	Comment 29 • 24 years ago

aoki,
- right mouse button in general is discussed on newsgroup .dom
- as shown with many examples here and as you can easily witness yourself at
many sites, the current solution has serious "compatibility" problems by being
triggered unintentionally (intended by neither the web developer nor the user).
Netscape Navigator 4.x (at least here on Unix) doesn't show this behaviour.

	Matthew T (active 1999-2002)
	Comment 30 • 24 years ago

> "Do not use your browser's back button for doing so will cause [multiple data
> submissions/lost data/general havoc]".

It is easy enough to do prevent such havoc on the server side, as Bugzilla 
demonstrates.

> If I'm a developer which is trying to use Mozilla as a platform to deliver
> application-like content

Then you need to keep in mind that it's not your Web browser. It's the user's. 
Not yours. Theirs. You need to accept the limitations of the medium (only one 
mouse button, no control over context menus), in return for the advantages you 
have gained (cross-platform execution, no need for installation on the user's 
machine, etc).

> and I want to provide other semantics on the right mouse button or explicitly
> prevent the contextual menu from popping up

Then not only would you be immensely annoying, but your app also wouldn't work 
in iCab, Navigator 4.x, Internet Explorer 5.0 for Mac OS, and probably other 
browsers which I haven't tested yet. Again, if Mozilla allows remote content to 
interfere with use of the right mouse button, then users will avoid it in favor 
of those browsers which don't.

	timeless
	Comment 31 • 24 years ago

mpt: well written. Why don't you encourage the same approach for accesskeys ;-?

	Matthew T (active 1999-2002)
	Comment 32 • 24 years ago

(I do -- see bug 55020.)

	Cesar Eduardo Barros
	Comment 33 • 23 years ago

I think the discussion should not be restricted to right click and context
menus. Middle click (open in new window/paste URL) has the same problem. See bug
70135:

Pretty annoying testcase:

http://www.elnet.com.br/elnet_news/index.asp

In the white-backgrounded middle column ("Notícias e Matérias"), every link is a
popup. In IE and 4x (it wasn't me who tested, but I saw it), middle-clicking or
right-clicking on any of them does what it's supposed to do, with no popup. The
popup only appears in left-click.

So, now I'm inclined to say "no pref, just block it!"


Getting left-click only is the most useful behavior (ie parity, 4x parity, and
the fact that you shouldn't have to check for the button in every onclick handler).

If the DOM has a way to know which button was pressed, this does not mean that
mozilla has to give a way to send presses of other buttons to scripting; it just
means that _if_ it does, which button was pressed should be available in a
specific way. Nobody here has said the DOM spec says "you must be able to send
clicks of all buttons to scripting".

	Ben Bucksch (:BenB) Reporter
	Comment 34 • 23 years ago

Removing "on a link" from SUMMARY again, since the bug is not limited to link,
as you can easily witness on Google's ads, e.g. currently at
<http://www.google.com/search?q=auto+buy>. See initial description.

	joki (gone) Assignee
	Comment 35 • 23 years ago

Moving lower priority bugs out of .9.2 milestone.

	joki (gone) Assignee
	Comment 36 • 23 years ago

*** Bug 81434 has been marked as a duplicate of this bug. ***

	Blake Ross
	Comment 37 • 23 years ago

Doesn't look like this is getting fixed before the freeze tomorrow night.
Pushing out a milestone.  Please correct if I'm mistaken.

	saari (gone)
	Comment 38 • 23 years ago

->0.9.5

	saari (gone)
	Comment 39 • 23 years ago

Hey, who made this topembed and why? Just making sure it really needs to be on
that radar. Thanks.

	Ken
	Comment 40 • 23 years ago

It was me. One of our developers has an issue with this, as right-clicking not 
only will pop a context menu, but also initiate the onclick (left click) event. 

Jud-Will this have to be yet another embeddor setting?

	Adam Lock
	Comment 41 • 23 years ago

I vote it should be fixed.

The DOM2-Events spec talks about these events occuring when a "pointing device
button" is pressed but I don't see anything that says Mozilla *must* generate
events for every button. As I interpret it, we could send events for every
button but then again we don't have to.

The current behaviour clearly screws with the context menus so it should be
changed for untrusted content. Chrome probably still needs to receive these
events whatever button was clicked.

	Olivier Cahagne
	Comment 42 • 23 years ago

*** Bug 89296 has been marked as a duplicate of this bug. ***

	Jesse Ruderman
	Comment 43 • 23 years ago

Bug 89296 also occurs with middle-clicking and ctrl+clicking.  Should those 
events also not be sent to untrusted content?

	Jesse Ruderman
	Comment 44 • 23 years ago

See bug bug 86193 for more discussion about whether pages should be able to 
interfere with context menus.  (Note that that's not exactly the same question 
as whether pages should see *onclick* for right-click events.)

	Judson Valeski
	Comment 45 • 23 years ago

this is broken behavior IMO. I suspect another manifestation of this is left
click selecting a mail message, than quickly right clicking it. That process
causes the messsage to be opened in a new window as though it had been double
left clicked. it's a major pain.

	Jesse Ruderman
	Comment 46 • 23 years ago

Valeski, that's covered by bug 86468, Left/Right clicks undiscriminated for 
double-clicks.  I don't know whether it's actually the same problem as the one 
in this bug.

	Boris Zbarsky [:bzbarsky]
	Comment 47 • 23 years ago

*** Bug 99822 has been marked as a duplicate of this bug. ***

	Marek Z. Jeziorek
	Comment 49 • 23 years ago

raising severity per embedding customer request

	joki (gone) Assignee
	Comment 50 • 23 years ago

Attaching patch.  This patch disables right and middle mouse clicks on all
content objects (with the exception of text fields due to a compatibility bug
with existing code).  It does not disable right and middle mouse clicks on
documents, windows, and in the browser chrome.  These events are already widely
used within the browser to provide internal functionality.  In addition, the
firing of middle and right clicks is correct per the DOM 2 Event spec and
required for the coding of complex applications.  No equivalent event exists. 
It is hoped that the current patch will fix all the bug cases in question.  It
has been tested and does fix the simple and common cases attached to this bug.

	David Hyatt
	Comment 52 • 23 years ago

sr=hyatt

	saari (gone)
	Comment 53 • 23 years ago

Comment on attachment 50941 [details] [diff] [review]
proposed patch

looks good to me, r=saari

	Christopher Aillon (sabbatical, not receiving bugmail)
	Comment 54 • 23 years ago

*** Bug 101841 has been marked as a duplicate of this bug. ***

	Jaime Rodriguez, Jr.
	Comment 55 • 23 years ago

Come to PDT @ noon to get your +, if no one gives it to you tonight.

	Jesse Ruderman
	Comment 56 • 23 years ago

joki, I'm confused about your comment:

>Attaching patch.  This patch disables right and middle mouse clicks on all 
>content objects
...
>the firing of middle and right clicks is correct per the DOM 2 Event spec and 
>required for the coding of complex applications.  No equivalent event exists. 

The first part sounds like you're not sending onclicks to web page objects, and 
the second part sounds like you are sending onclicks to them.  What am I 
missing?

	Jesse Ruderman
	Comment 57 • 23 years ago

Does the patch do anything to ctrl+left-clicks?  Ctrl+clicking on a link has 
the same meaning to the user as middle-clicking it, so it would seem strange if 
web pages accidentally intercepted one but not the other.  On the other hand, 
javascript minesweeper games need some way to know whether you're trying to 
mark a mine or dig in a square.  At least one minesweeper game 
(http://www.the5k.org/description.asp/entry_id=508) tells Mozilla users to 
ctrl+click instead of right-clicking in order to mark mines.

	selmer (gone)
	Comment 58 • 23 years ago

Moving to nsbranch+, please attend one of today's PDT meetings.  What kind of
testing needs to be done to ensure this does not introduce any regressions?

	Jaime Rodriguez, Jr.
	Comment 59 • 23 years ago

check it in - PDT+. 

Pls update Patch Status with "has super review"

	joki (gone) Assignee
	Comment 60 • 23 years ago

Fix checked into branch 9/27.  Will go into trunk today, 9/28.

	Alfonso Martinez
	Comment 61 • 23 years ago

*** Bug 102149 has been marked as a duplicate of this bug. ***

	joki (gone) Assignee
	Comment 62 • 23 years ago

Moving to 0.9.6 at request of drivers@mozilla.org

	lchiang
	Comment 63 • 23 years ago

Verified this on the 094 branch builds Win32 and Mac for the original test case
and for Jud Valeski's case re: mail.

However, for the testcase above dated 9-19, I do get the alert on the Mac, but
not on Win32.  I suspect this is because on the Mac, I don't have a left/right
mouse button.

	Marek Z. Jeziorek
	Comment 64 • 23 years ago

since this bug was checked in to 0.9.4, I'm removing topembed designation.
Please  make sure that the problem is also fixed on the branch (for future
embedding clients). Thanks.

	Boris Zbarsky [:bzbarsky]
	Comment 65 • 23 years ago

Um... This patch does not define a default value for mLeftClickOnly.  If the
pref is not set for some reason, we'll default to a randomly determined
state....  We should really initialize this bool.

	joki (gone) Assignee
	Comment 66 • 23 years ago

You're absolutely correct but that actually got noticed before the fix got
checked in so the trunk version has the preset bool.  I guess we never got the
patch updated for the minor revision.

And since this is on the trunk at this point I'm going to go ahead and close this.

	Ken
	Comment 67 • 23 years ago

So does the 0.9.4 branch properly set the default value? If not, can that be 
pushed?

	Marcia Knous [:marcia]
	Comment 68 • 23 years ago

EDT - added comment fixed0.9.4. talked to tom- the default value is properly
set on the branch. 

	Judson Valeski
	Comment 69 • 23 years ago

removing edt0.9.4 nomination.

	publicjanak
	Comment 70 • 16 years ago

This attachment shows a bug with right-click on google results pages when signed into a google account and using web history.  This bug does not exist in IE or Chrome.  Google appears to change the target of the link, using javascript, when the user clicks on it.  However, the link is also changed when the user right-clicks on it, which is not the expected behavior.  This can be reproduced by anyone when signed into a google account with web history enabled.