From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0rc3) Gecko/20020527 BuildID: 2002052818 When you use middle click on the composer scroll bar to move to a certain position, the cut buffer will get inserted above the edited page . It does move you to the position you indicated, so that's at least something :) Reproducible: Always Steps to Reproduce: 1.open composer on a page 2.make sure you have some recognizable text in your cut buffer (select some text with the mouse) 3.middle click somewhere on the vertical scroll bar Actual Results: This will move you to where you indicated, and insert the cut buffer on top of the page Expected Results: It should only have moved to where you indicated. This is a custom build 1.0rc3, built against the sun gnome 1.4 gtk libraries.

On Linux, the middle mouse button is commonly used to paste the clipboard contents. Is Solaris the same? If so, -> INVALID ?

Yes, Solaris also uses middleclick to paste the cut buffer. (It's really an X thing). But middleclick on a scrollbar should not paste into the document, it should move you in the document so that the scrollbar grab thingie is centered around your cursor. I don't know what you mean with INVALID, but I'm guessing it does not apply right now.

It should not insert. It should work as Wout.Mertens describes: scroll to the location of the click without affecting content. The insertion of clipboard contents happens in nsTextEditorMouseListener::MouseClick. It seems wrong that that method is called for a click in the scrollbar, not in the content area. Charley, Kathy, does this sound like it might be related to the other click-in-scrollbar regressions?

The bug that it sounds most like (to me) is bug 134503 which is still fixed on both trunk and in Netscape's PR1 build. Akkana--can you test if we are getting into EditorClick function (in editor.js) by adding a dump? Do we get there before or after the mouselistener MouseClick method is called?

We are not calling EditorClick. We are calling nsTextEditorMouseListener::MouseClick. The scrollbar handles the event first, doing the correct thing for the middle click; then the editor handles the same event. I tried adding the following at the beginning of MouseClick: // Don't handle the event if it's already been handled. nsCOMPtr<nsIDOMNSUIEvent> nsUIEvent = do_QueryInterface(aMouseEvent); if(nsUIEvent) { PRBool prevented; nsUIEvent->GetPreventDefault(&prevented); if (prevented) return NS_OK; nsUIEvent->GetCancelBubble(&prevented); if (prevented) return NS_OK; } but it didn't help. It looks like the scrollbar isn't preventing default/bubble. Adding saari -- maybe he knows something about how this should work, or can point us to someone else who can help.

i once reported this in bug 82513

*** This bug has been marked as a duplicate of 70698 ***

verified.

reassign in case bugs are later reopened