Closed Bug 74688 Opened 24 years ago Closed 22 years ago

Contextual Menu popup at scroll bar of message pane

Categories

(Core :: XUL, defect)

Product:
Core
Component:
XUL
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.0.1

People

(Reporter: tarahim, Assigned: jag+mozilla)

References

Details

(Keywords: helpwanted, relnote, topembed+, Whiteboard: [driver:blizzard][adt2 rtm])

Attachments

(1 file, 1 obsolete file)

Fix v2
2.25 KB, patch
samir_bugzilla
: review+
jag+mozilla
: superreview+
asa
: approval+
Details | Diff | Splinter Review 
2001040309 trunk.
Although most of the Contextual Menu popup problem of click-hold has been solved
in bug 74380, there are some Mail/News window items that have escaped the fix.
1)In mail/news window, the scroll bars for the side bar and the message pane do
not follow the Appearance control panel settings, and they respond to click-hold
to invoke contextual menu.
2)The thread pane list setting button shows contextual menu before the list of
settings appear.
Build 2001-04-04-08: Mac 9.04

hirata: 
1. In the Appearance control panel what settings do you have? I selected the 
Options tab and selected Smart Scrolling. In Mail when I place the cursor on the 
up/down arrow button in the Sidebar a context menu does not appear. Without 
using Smart Scrolling the context menus still do not appear.

2. What is meant by the "thread pane list setting button"? Do you mean the 
"column selector widget"? This is the button that appears to the far right of 
the 3pane column headers. When selected it shows a list of available columns. If 
I select and hold the mouse then a list of columns appear followed by a context 
menu. I don't see the problem with the context menu appearing first.
QA Contact: esther → nbaca
1. In my Appearance Control Panel, I have activated hidden feature to have two
arrows on both ends of the scroll bar. The scroll bars of the message pane and
sidebar do not show two arrows on either end.
2. Contextual Menu comes up before the list of coulmns when the column selecter
widget has been pressed but nothing been changed, and then the widget is pressed
for the second time.
Utility for chaning hidden scrollbar settings:
<http://www.polymorph.net/prestissimo.html>

Using Prestissimo I have enabled the double arrows to appear at both ends of the
scrollbar. I have noticed:

- Navigator: Double scrollbars appear in the Sidebar but the main area to the
right only has the single arrows on each end. When I go to a differnet site it 
forces a redraw and the double arrows appear.
- Mail (3pane): Double scrollbars appear for the Folder pane, Thread pane and
Sidebar but the Message pane only shows the single arrows on each end. After
selecting a message, that requires a scrollbar, then the double arrows appear. 

Additional questions
- What Mac OS version are you using?
- How does the Navigator window appear? 



This is Japanese Mac OS 9.1.
I have seen double scroll arrows in the sidebar only once or twice in either
Navigator or Mail. Most of the time, there are single arrows on both ends.
I never get double arrows in Message pane or in an independent message window.
Otherwise, they appear as you describe for Navigator and Mail/News.
I used 2001040309 trunk on MacOS J1-9.0.4.
I got about the same result as Nanoschka except I could not see the double arrow
at all in a separate message window.

I'm not sure if this is a mailnews bug or not.  Does this sound like it could be
a layout or toolkit bug (I'm not sure who is responsible for double scrollbars)
*** Bug 78525 has been marked as a duplicate of this bug. ***
see also bug 61826 and bug 62466 for scroll bar problem.
on a recent CVS build, Linux, there are now context menus on scrollbars in
mailnews, browser and composer. Also on editor form scrollbars in page content.
The only place i don't see them is in AB and autocomplete (which no longer
completes anything, but instead has turned into a context menu of it's own)
*** Bug 78578 has been marked as a duplicate of this bug. ***
I see this in the browser window. 05/02 build. Just click and hold the scroll
thumb and the contextual menu will pop up. Very annoying. Definitely *not* a
Mail/News-only problem.
OK. i can confirm that this is happening in Browser windows if Modern theme is
used. Must be a regression from a new Modern. Might as well be files as a
separate bug.
I am keeping this one as a bug for non-Appearance compliant scroll tab and other
widgets, and reopening bug 78525 for Modern theme.
Is this bug about scrollbars having a context menu, or about scrollbars not 
following the Smart Scrolling prefs? I don't see how the two problems can be 
related.
This one is about the contextual menu. The bug 62466 should deal with Appearance
uncompliance. I do not think it is a coincidence that the popups are brought up
at those widgets, is it?
*** Bug 91575 has been marked as a duplicate of this bug. ***
FWIW, in Bug 91575 (dup of this), I noted that this behavior occurs on MacOSX as
well. 


*** Bug 93867 has been marked as a duplicate of this bug. ***
I would like to confirm that I see the context menu pop up when using the mail
message pane's scroll bar (MacOS 9.2.1, Moz 20010827).  This is the ONLY scroll
bar I have found that that exhibits this behavior (and I've looked all over). 
As other commenters have implied, I suspect that this bug is related to bug
62466 "Scroll bar setting in Appearance not observed in Message pane".  I also
would like to note that the View Source window suffers from bug 62466 and I
(amateurishly) suspect that it would suffer from this bug too if it had a
context menu, since these are the two places in the application where changes in
the system scrollbar have not propagated.  Is there some separate API that the
mail message pane and the view source window are using that is different from
the rest of the apps scrollbars?




Could we have *some* movement on this bug please? Scrolling long messages is
nearly impossible on MacOS, because if you try to use the slider to scroll, you
often get a popup instead.
As a stopgap measure for MacOS users, if you click on the scollbar and don't
move it within a second, the contextual menu pops up and makes a real nuisance
of itself. However, you can decrease the scrolling problem a bit by moving the
scrollbar up/down a little right away before the contextual menu pops up to
prevent its opening.


*** Bug 100525 has been marked as a duplicate of this bug. ***
*** Bug 101215 has been marked as a duplicate of this bug. ***
*** Bug 109075 has been marked as a duplicate of this bug. ***
Enabling JS in Mail/News makes the problem go away (and bug 62466 goes away too
then).  This is related to 61826, the security manager seems to stop the load of
the scrollbar bindings.
I submit that this is not a Mac-only bug, merely a Mac-only problem. 
Right-clicking a scrollbar in win32 shouldn't open a contextual menu either -
it's just not a problem if it does.  I verified that this behavior occurs with
2001110903 on win2k.
QA Contact: nbaca → olgam
*** Bug 113712 has been marked as a duplicate of this bug. ***
Nominating for the next release.  This bug makes it very difficult to scroll
through a long email using the scroll bar thumb.
Keywords: nsbeta1
reassigning to ssu.
Assignee: sspitzer → ssu
Keywords: nsbeta1 → nsbeta1+
Priority: -- → P2
Status: NEW → ASSIGNED
Severity: normal → major
Is this really a nsbeta1+, P2? If yes, then we need to try and targeted to a
milestone M1.0 or earlier to make the beta.
Severity: major → critical
*** Bug 123567 has been marked as a duplicate of this bug. ***
This bug is a major pain on the Mac. How was the problem solved in the browser?
I recall it used to something similar but doesn't anymore.
Blocks: 122274
Keywords: nsbeta1+ → nsbeta1-
The obvious solution:  don't make scrollbars right-clickable.  As far as I can
tell, no other scrollbars anywhere respond to a right-click; only the scrollbars
in the message preview pane.  A cross-platform solution that doesn't break
anything.  Anyone disagree that that's the right approach?
I believe this bug should be nsbeta+. It interferes with mail/news use in a very
obvious and annoying way.
I agree.
major usability issue. requesting re-triage.
Keywords: nsbeta1- → nsbeta1
Keywords: mozilla0.9.9, nsdogfood
Priority: P2 → --
No longer blocks: 122274
Keywords: nsbeta1 → nsbeta1-
comment 26 is wrong :-), see bug 38466.
What is the usability justification for marking this nsbeta1- twice?  This is a
basic functionality bug, preventing one from scrolling through any long email
message.
Blocks: 122050
Alrighty then.  Scrollbars on win32 should have contextual menus; scrollbars on
Mac should not.  That solves the problem, without needing to explicitly disable
click-and-hold.

Or do you think Mac scrollbars should have contextual menus (via control-click
or right-click) anyway, even though it's not a standard feature on that platform
and no other apps (to my knowledge) do it?  I can see it being kinda neat, but
on the other hand, it'll be unexpected behavior.  But then again, it shouldn't
interfere with anything; if the user doesn't expect the feature, they just won't
right-click there.

I'm able to reproduce this under win2k as well.  Here's how to reproduce the bug:
1) open a browser and mailnews window
2) open up the preferences to the Advanced|Scripts & Windows category
3) uncheck the 'Enable JavaScrip for' checkboxes for:
     Navigator
     Mail & Newsgroups
4) Click OK to accept and close the preferences.

Under Win2k, simply right mouse click on the scrollbar (in either the browser or
mailnews window that have scrollbars) and the context menu will appear.
Under MacOS 9x, simple click and hold the mouse button (without moving it) on
the scrollbar.  The context menu will appear in about 1 second.

This is not a mailnews bug.
No longer blocks: 122050
Component: Mail Window Front End → XP Toolkit/Widgets
OS: Mac System 9.x → All
Product: MailNews → Browser
Target Milestone: --- → mozilla0.9.9
resetting bug to default component owner
Assignee: ssu → jaggernaut
Status: ASSIGNED → NEW
QA Contact: olgam → jrgm
I have 'Enable JavaScrip for' enabled for both Navigator and Mail & Newsgroups 
on Mac OS9 and don't get the scrollbar.
I have JavaScript enabled for Navigator but not Mail & News.  Build 2002020406
on Win2k.  When I right-click the scrollbar, I get a contextual menu.  Note that
it's not the menu suggested by bug 38466, it's the same as you'd get if you
right-clicked elsewhere in the preview pane.

It only happens on the preview pane (the bottom half of the window, not the top
half where the list of messages are, and nowhere else that I know of).
Javascript needs to be disabled to see this bug, so you need to uncheck the
checkboxes (as Sean Su noted). I'm definitely seeing this on MacOS 9.
-> 1.1
Target Milestone: mozilla0.9.9 → mozilla1.1
Just a thing I'm wondering...

I've enabled "smart scrolling" in my Mac OS, that is, both the scroll bars'
buttons are placed at the bottom or the right of the bar. That's how it is
almost everywhere, except the message pane in Mail & News. Now, I don't know
anything about how the widgets are programmed and used, but to me it looks like
a wrong kind of scroll bar is being used in that pane. And it's the only scroll
bar with the contextual menu problem too, so to me that reinforces that theory...
Well, that's what bug 62466 is about, it is very likely that these have the same
cause and can be marked duplicate. Still, someone should investigate the cause
first.
Now that we're in a different component, let's re-triage nsbeta1 again.  This is
a basic mail functionality bug on the Mac and seriously impedes viewing long
mail messages.  It's also a security bug -- the only workaround is to enable
JavaScript for mail, which, given the kind and amount of spam I've gotten, is
most unwise.
Keywords: nsbeta1- → nsbeta1
Maybe this bug should be split in two (since I haven't seen anybody pay
attention to the second part). This behavior also occurs with the column
settings widget, and not just in Mail/News - happens in manage bookmarks window,
too. This is a big problem since the contextual menu is displayed on top of the
column settings menu, making it impossible to show/hide columns without a lot of
guessing. It ALSO occurs with click and hold on the column heading/title in
Mail/News and bookmarks (manage window and sidebar).

This is a killer on Mac OS X (although it may not be an issue with Mac OS 9).
nsbeta1- per Nav triage team.  nominating for mozilla1.0/helpwanted, in hope
that someone who cares about it can fix it.
Keywords: nsbeta1 → helpwanted, mozilla1.0, nsbeta1-
CCing Blake who fixed a similar issue in the browser popup just yesterday for
bug 122302.

marking topembed because this could affect a particular 3rd party mail reader in
the near future
Keywords: topembed
Keywords: mozilla0.9.9
Blocks: 122050
I'm not sure which of the issues described in this bug are mac event handling 
issues.
1. Click-hold on the outliner column picker widget (the "settings button of 
thread pane" of the summary) is an XP bug; the same happens if you right-click 
it. I filed bug 125609 on this.

2. Context menus on message pane scrollbar are obviously wrong. But I still don't 
think this is an events issue; it seems more XUL-related to me.
Summary: Contextual Menu popup at scroll bar of message pane and settings button of thread pane → Contextual Menu popup at scroll bar of message pane
I suppose that the scroll bar of the message pane is treated differently from
other scroll bars as this is the only scroll bar that does not follow
double-arrow settings of Apearance control.(bug 62466)
Would this contextual menu bug be fixed if bug 62466 got fixed?
Well, comment 54 explains why there's a context menu.  Why isn't the
xul:scrollbar (scrollbar.xml) being used (and what is)?
hrm, I've tracked down it in JS at least.

mailWindow.js:
function InitMsgWindow()
{
  msgWindow.messagePaneController = new nsMessagePaneController();
  msgWindow.statusFeedback = statusFeedback;
  msgWindow.msgHeaderSink = messageHeaderSink;
+ return;
  msgWindow.SetDOMWindow(window);
  mailSession.AddMsgWindow(msgWindow);
}

So after SetDOMWindow() I see this problem.
Weird...
another step:
SetDOMWindow()
  SetRootDocShell();
    aDocShell->SetAppType(nsIDocShell::APP_TYPE_MAIL); 


Index: nsMsgWindow.cpp
===================================================================
RCS file: /cvsroot/mozilla/mailnews/base/src/nsMsgWindow.cpp,v
retrieving revision 1.69
diff -u -r1.69 nsMsgWindow.cpp
--- nsMsgWindow.cpp	29 Jan 2002 21:56:19 -0000	1.69
+++ nsMsgWindow.cpp	21 Feb 2002 18:51:28 -0000
@@ -303,7 +303,7 @@
     aDocShell->SetParentURIContentListener(this);
	// be sure to set the application flag on the root docshell
	// so it knows we are a mail application.
-
aDocShell->SetAppType(nsIDocShell::APP_TYPE_MAIL);
+//
aDocShell->SetAppType(nsIDocShell::APP_TYPE_MAIL);
   }
   return NS_OK;
 }


and in nsScriptSecurityManager.cpp we have

     //-- See if JS is disabled globally (via prefs)
    *result = mIsJavaScriptEnabled;
    if ((mIsJavaScriptEnabled != mIsMailJavaScriptEnabled) && docshell)
    {
        // Is this script running from mail?
        PRUint32 appType;
	rv = docshell->GetAppType(&appType);
        if (NS_FAILED(rv)) return rv;
        if (appType == nsIDocShell::APP_TYPE_MAIL)
            *result = mIsMailJavaScriptEnabled;
  	}
    if (!*result)
        return NS_OK;
 
so when we have JS disabled in mail, it disables JS in XBL too (scrollbars XBL)

hyatt suggested, at one point, that XBL be extended to allow for a declarative 
way to do the prevent default, so that JS was not required to run. 
e.g., instead of
   <handler event="contextmenu" action="event.preventDefault();"/> 
do
   <handler event="contextmenu" preventdefault="true"/> 

(Apologies if I've misquoted hyatt, and I don't know if 
'preventdefault="true"' is exactly what he intended).





that might work, *but* we need to run initScrollbar() too

(/me casually ignored all the JS immediately above that handler :-). Yes, to 
fix bug 62466, and have smart scrollbars work in the message pane, you need to 
run initScrollbars(). So, a declarative syntax for <handler/> wouldn't solve 
both problems.
Someone remind me again why scrollbars are in content, not chrome?

The vertical and horizontal scroll bars for the Print Preview window are
affected, too.
This is on the 0.9.9 bug list.  Where are we with this?
Whiteboard: [driver:blizzard]
I wasn't aware that this bug was on Mozilla.org's "would like to see this fixed
for 0.9.9" list, so I hadn't (and still haven't) started any work on it yet. The
fix looks to be non-trivial, so I doubt I can have a patch for 0.9.9. Since it's
also nsbeta1-, it isn't at the top of my list of things to fix.
Target Milestone: mozilla1.1 → mozilla1.0
Yay, it seems that this is fixed after mstoltz's checkin today.

It's still broken in today's build (2002022808).
No longer blocks: 122050
Uhm, sorry I had modified nsMsgWindow.cpp file.

Still broken as of build 2002030803. :(
Argh, I dont know whats up, but this happens to me too when I click the mouse on
a folder in my personal toolbar, whitout moving it.

Build:2002030803

Steps to reproduce:
1. have a folder (possible with content) in the personal toolbar
2. Click and hold the mouse without moving it (on the folder :)


I think this may be a design, but it is at least verry poorly, because there is
no way to turn of the menu without releasing it and pressing the mouse again. So
if I  just open the menu and think about what to click, I´l get a little bit
anoyed every time....


So please turn it off there too!

:) Martin
Mass-moving all Navigator team 1.0 nsbeta1- bugs to 1.1
Target Milestone: mozilla1.0 → mozilla1.1
plusing to topembed+ as per edt triage.
Keywords: topembed → topembed+
*** Bug 133655 has been marked as a duplicate of this bug. ***
*** Bug 137828 has been marked as a duplicate of this bug. ***
I'm still finding this in 1.0 rc 1, on MacOS 9.2.2 and 10.1.3, in both Navigator
and Messenger windows (so it's not really a mail/news problem), depending on the
setting of javascript on/off.

Scrollbars do not have double arrows, and contextual menu pops up on long click
on the thumb if javascript is off. I would say it's a major useability problem,
and if it can't be fixed, should at least be noted in "known issues" document
with workaround (turn on javascript).
*** Bug 138964 has been marked as a duplicate of this bug. ***
Adding Relnote KW, in accordance with comment #74.
Keywords: relnote
*** Bug 140926 has been marked as a duplicate of this bug. ***
*** Bug 141978 has been marked as a duplicate of this bug. ***
Showed up in 1.0 RC 1 again.  This is quite a show stopper for serious mail
users. I actually started using another mailer due to this.  Read here that
turning on javascript would fix.  Tried it and it worked.  Possibly should make
default until bug resolved?
*** Bug 142622 has been marked as a duplicate of this bug. ***
*** Bug 145093 has been marked as a duplicate of this bug. ***
Requesting re-triage for Netscape 7 RTM.  With JavaScript now turned off by
default in mail, this bug will now prevent all MacOS 9 email users from
scrolling through their messages using the scroll bar.  It's now a very high
impact bug.
Keywords: nsbeta1- → nsbeta1
OS: All → Mac System 9.x
Nav triage team: nsbeta1+, adt2 rtm
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [driver:blizzard] → [driver:blizzard][adt2 rtm]
Target Milestone: mozilla1.1alpha → mozilla1.0.1
This is most visible on Mac yet exists on all platforms -- right click on the
scrollbar and you'll see the behavior too.  Also it's not limited to mailnews,
if you disable JS in navigator you'll also be able to observe this behavior...
OS: Mac System 9.x → All
Hardware: Macintosh → All
Attached patch Hacky fix (obsolete) — — Splinter Review 
Jag and I came up with this patch which works, although it seems sortof
hacky...  just putting context="" on the <content> didn't seem to work....
minusing this. please re-nominate (by removing the '-' on the mozilla1.0.1
keyword and sending mail to drivers) once this has landed and baked on the trunk
for at least two days.
Keywords: mozilla1.0.1-
Attached patch Fix v2 — — Splinter Review 
Also remove the <handler> if we're doing it this way...

So I've been told that since the scrollbar's binding is in content there's no
good way to say that it's allowed to run the JS there (event.preventDefault()
).

So this seems to be the best fix for us, and probably the least risky...
Attachment #85703 - Attachment is obsolete: true
Comment on attachment 85787 [details] [diff] [review]
Fix v2

sr=jag (can I technically do this, since I came up with this solution? ;-)
Attachment #85787 - Flags: superreview+
Comment on attachment 85787 [details] [diff] [review]
Fix v2

r=sgehani contigent upon testing on a classic mac.
Attachment #85787 - Flags: review+
Comment on attachment 85787 [details] [diff] [review]
Fix v2

a=asa (on behalf of drivers) for checkin to the 1.1 trunk
Attachment #85787 - Flags: approval+
Landed on the trunk.  I'll get branch approval next week.  Also after talking
with hyatt, the real fix is to add a preventdefault="true" attribute set to
handler elements.  I've filed bug 149474 for that additional work.
Status: NEW → RESOLVED
Closed: 22 years ago
Depends on: 149474
Resolution: --- → FIXED
*** Bug 149404 has been marked as a duplicate of this bug. ***
Nominating for adt1.0.1 -- this is in Mozilla 1.1 with no regressions noticed. 
This is a highly valuable fix for users on Mac OS Classic -- not fixing this
basically prevents them from usefully using our browser.
Keywords: mozilla1.0, mozilla1.0.1- → adt1.0.1, mozilla1.0.1
jrgm, could you verify this on the trunk?
ok, this bug is marked as "resolved/fixed" with no side-effects, so perhaps what i'm seeing in 1.1 are unrelated bugs:

- click-drag to pull the scrollbar handle doesn't always work.  it seems to
  just stay stuck from the time i opened up mozilla for the first time until i
  switched to another app and back ...

- click-hold in the scrollbar doesn't behave exactly like most other mac apps.
  e.g. take a lengthy page like the URL for this bug.  with the scrollbar
  handle near the top, click-hold in the scrollbar pane about halfway down and
  wait for the handle to page down that far -> so far, so good.  but now, if
  while still mousedown, attempting to move the pointer immediately to about
  3/4 down, nothing else happens, whereas in most other apps, the scroll bar
  will page down until it gets to the new spot.  another slight 'deviation' is
  that, starting with the handle at the top again, click-hold near the bottom,
  but then before the handle gets there, move to about halfway down.  in other
  apps, this will cause scrolling to stop at the intersection of where your
  mouse is and where the scrollbar handle is.  but in mozilla, scrolling
  continues all the way to the original point at which you performed the
  mousedown, often beyond where you are holding the pointer steady.

marking adt1.0.1- per ADT.
Keywords: adt1.0.1 → adt1.0.1-
Johndoe, I would say those are separate bugs which aren't related to this.  Can
you please file two separate bug reports and assign/cc me?  Thanks.
reversing the decision and adding adt1.0.1+ since it sounds like this makes mail
unusable on the Mac.
Keywords: adt1.0.1- → adt1.0.1+
please checkin to the 1.0.1 branch. once there, remove the "mozilla1.0.1+"
keyword and add the "fixed1.0.1" keyword.
Keywords: mozilla1.0.1 → mozilla1.0.1+
*** Bug 160229 has been marked as a duplicate of this bug. ***
esther - can you verify?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: