If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Contextual Menu popup at scroll bar of message pane

RESOLVED FIXED in mozilla1.0.1

Status

()

Core
XUL
--
critical
RESOLVED FIXED
17 years ago
4 years ago

People

(Reporter: hirata masakazu, Assigned: jag (Peter Annema))

Tracking

({helpwanted, relnote, topembed+})

Trunk
mozilla1.0.1
helpwanted, relnote, topembed+
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [driver:blizzard][adt2 rtm])

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

17 years ago
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.

Comment 1

17 years ago
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
(Reporter)

Comment 2

17 years ago
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.

Comment 3

17 years ago
Utility for chaning hidden scrollbar settings:
<http://www.polymorph.net/prestissimo.html>

Comment 4

17 years ago
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? 


(Reporter)

Comment 5

17 years ago
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.

Comment 6

17 years ago
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.

Comment 7

17 years ago
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)
(Reporter)

Comment 8

17 years ago
*** Bug 78525 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 9

17 years ago
see also bug 61826 and bug 62466 for scroll bar problem.

Comment 10

17 years ago
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)

Comment 11

17 years ago
*** Bug 78578 has been marked as a duplicate of this bug. ***

Comment 12

17 years ago
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.
(Reporter)

Comment 13

17 years ago
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.

Comment 14

17 years ago
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.
(Reporter)

Comment 15

17 years ago
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?
(Reporter)

Comment 16

16 years ago
*** Bug 91575 has been marked as a duplicate of this bug. ***

Comment 17

16 years ago
FWIW, in Bug 91575 (dup of this), I noted that this behavior occurs on MacOSX as
well. 

Comment 18

16 years ago
*** Bug 93867 has been marked as a duplicate of this bug. ***

Comment 19

16 years ago
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.

Comment 21

16 years ago
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.

Comment 22

16 years ago
*** Bug 100525 has been marked as a duplicate of this bug. ***

Comment 23

16 years ago
*** Bug 101215 has been marked as a duplicate of this bug. ***

Comment 24

16 years ago
*** 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.

Comment 26

16 years ago
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.

Updated

16 years ago
QA Contact: nbaca → olgam

Comment 27

16 years ago
*** Bug 113712 has been marked as a duplicate of this bug. ***

Comment 28

16 years ago
Nominating for the next release.  This bug makes it very difficult to scroll
through a long email using the scroll bar thumb.
Keywords: nsbeta1

Comment 29

16 years ago
reassigning to ssu.
Assignee: sspitzer → ssu
Keywords: nsbeta1 → nsbeta1+
Priority: -- → P2

Updated

16 years ago
Status: NEW → ASSIGNED
Severity: normal → major

Comment 30

16 years ago
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.

Updated

16 years ago
Severity: major → critical

Comment 31

16 years ago
*** Bug 123567 has been marked as a duplicate of this bug. ***

Comment 32

16 years ago
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.

Updated

16 years ago
Blocks: 122274
Keywords: nsbeta1+ → nsbeta1-

Comment 33

16 years ago
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?

Comment 34

16 years ago
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

Updated

16 years ago
Keywords: mozilla0.9.9, nsdogfood
Priority: P2 → --
No longer blocks: 122274

Updated

16 years ago
Keywords: nsbeta1 → nsbeta1-

Comment 37

16 years ago
comment 26 is wrong :-), see bug 38466.

Comment 38

16 years ago
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.

Updated

16 years ago
Blocks: 122050

Comment 39

16 years ago
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.

Comment 40

16 years ago
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

Comment 41

16 years ago
resetting bug to default component owner
Assignee: ssu → jaggernaut
Status: ASSIGNED → NEW
QA Contact: olgam → jrgm

Comment 42

16 years ago
I have 'Enable JavaScrip for' enabled for both Navigator and Mail & Newsgroups 
on Mac OS9 and don't get the scrollbar.

Comment 43

16 years ago
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.
(Assignee)

Comment 45

16 years ago
-> 1.1
Target Milestone: mozilla0.9.9 → mozilla1.1

Comment 46

16 years ago
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.

Comment 48

16 years ago
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

Comment 49

16 years ago
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).

Comment 50

16 years ago
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-

Comment 51

16 years ago
CCing Blake who fixed a similar issue in the browser popup just yesterday for
bug 122302.

Comment 52

16 years ago
marking topembed because this could affect a particular 3rd party mail reader in
the near future
Keywords: topembed

Updated

16 years ago
Keywords: mozilla0.9.9

Updated

16 years ago
Blocks: 122050

Comment 53

16 years ago
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
(Reporter)

Comment 54

16 years ago
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?

Comment 55

16 years ago
Well, comment 54 explains why there's a context menu.  Why isn't the
xul:scrollbar (scrollbar.xml) being used (and what is)?

Comment 56

16 years ago
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...

Comment 57

16 years ago
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)

Comment 58

16 years ago
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).




Comment 59

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

Comment 60

16 years ago
(/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.

Comment 61

16 years ago
Someone remind me again why scrollbars are in content, not chrome?
(Reporter)

Comment 62

16 years ago
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]
(Assignee)

Comment 64

16 years ago
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

Comment 65

16 years ago
Yay, it seems that this is fixed after mstoltz's checkin today.

Comment 66

16 years ago
It's still broken in today's build (2002022808).

Updated

16 years ago
No longer blocks: 122050

Comment 67

16 years ago
Uhm, sorry I had modified nsMsgWindow.cpp file.

Comment 68

16 years ago
Still broken as of build 2002030803. :(

Comment 69

16 years ago
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

Comment 70

16 years ago
Mass-moving all Navigator team 1.0 nsbeta1- bugs to 1.1
Target Milestone: mozilla1.0 → mozilla1.1

Comment 71

16 years ago
plusing to topembed+ as per edt triage.  
Keywords: topembed → topembed+
(Reporter)

Comment 72

16 years ago
*** Bug 133655 has been marked as a duplicate of this bug. ***

Comment 73

16 years ago
*** Bug 137828 has been marked as a duplicate of this bug. ***

Comment 74

16 years ago
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).

Comment 75

16 years ago
*** Bug 138964 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 76

16 years ago
Adding Relnote KW, in accordance with comment #74.
Keywords: relnote

Comment 77

16 years ago
*** Bug 140926 has been marked as a duplicate of this bug. ***

Comment 78

16 years ago
*** Bug 141978 has been marked as a duplicate of this bug. ***

Comment 79

16 years ago
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?

Comment 80

16 years ago
*** Bug 142622 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 81

16 years ago
*** Bug 145093 has been marked as a duplicate of this bug. ***

Comment 82

16 years ago
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

Comment 83

16 years ago
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
Created attachment 85703 [details] [diff] [review]
Hacky fix

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....

Comment 86

16 years ago
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-
Created attachment 85787 [details] [diff] [review]
Fix v2

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
(Assignee)

Comment 88

16 years ago
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 89

16 years ago
Comment on attachment 85787 [details] [diff] [review]
Fix v2

r=sgehani contigent upon testing on a classic mac.
Attachment #85787 - Flags: review+

Comment 90

16 years ago
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
Last Resolved: 16 years ago
Depends on: 149474
Resolution: --- → FIXED

Comment 92

16 years ago
*** 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

Comment 94

16 years ago
jrgm, could you verify this on the trunk?

Comment 95

16 years ago
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.

Comment 96

16 years ago
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.

Comment 98

16 years ago
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+

Comment 99

16 years ago
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+
Landed on the branch
Keywords: mozilla1.0.1+ → fixed1.0.1
(Reporter)

Comment 101

15 years ago
*** Bug 160229 has been marked as a duplicate of this bug. ***

Comment 102

15 years ago
esther - can you verify?
You need to log in before you can comment on or make changes to this bug.