Closed Bug 75866 Opened 24 years ago Closed 21 years ago

Viewing message for very short time shouldn't mark it as read

Categories

(SeaMonkey :: MailNews: Message Display, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: joschi, Assigned: mscott)

References

Details

Attachments

(2 files, 2 obsolete files)

From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; 0.8.1) Gecko/20010412 BuildID: 2001041212 If you move quickly with the arrow keys past a message, the mail reader should not mark that message as read. maybe just a little .2 second delay before marking it as read. This is a big usability bug becuase users often use arrow keys to move around. Users often read messages out of order, and like to keep the unread status so they know what needs to be read yet.
sounds like a job for timedSelect
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
I think 0.2 seconds is far too short, especially when a user is (for example) pressing the Down key to go to the next message, then releasing the key, then pressing it again. I suggest 2.0 seconds instead. It's pretty impossible to read a message quicker than that. :-) [#include std-no-it-does-not-need-to-be-a-pref.h]
OS: Windows 2000 → All
Hardware: PC → All
Summary: mail index should not mark message read when you move quickly past it → Viewing message for very short time shouldn't mark it as read
The version of MS Outlook with which I am familiar (97?) has, as I recall, what's effectively a three-way pref for this (bearing in mind that messages can always be marked read or unread manually): 1. Mark messages as read as soon as they're selected 2. Mark messages as read after they've been selected for n seconds 3. Mark messages as read only when they've been double-clicked 1 may just be the case where n=0; I don't recall. I prefer 3, myself -- I tend to leave messages marked unread until I've dealt with them fully.
Yes, please make a pref for this. I would really rather not have to wait 2 seconds for junk mail and mailing list traffic that I tend to give much less than 2 secs of my attention to :-)
i just wanted to clear this up, it wouldn't prevent you from deleting or reading an email for that time period, merely wouldn't mark it as read for a reasonable time. The negative effect to the user would be near zero.
Matthew: isn't this a quite good example of something that actually should be a pref? I know that you default to "no", but can't you consider this a pref and then share your thoughts? Bounce to UI: Design Feedback for investigation.
Assignee: sspitzer → mpt
Status: ASSIGNED → NEW
Component: Mail Window Front End → User Interface Design
Product: MailNews → Browser
QA Contact: esther → zach
um. jglick and robinf are the people who should be writing the rules, this is not browser.
Assignee: mpt → jglick
Component: User Interface Design → Mail Window Front End
Product: Browser → MailNews
QA Contact: zach → esther
Um. Timeless, you know very well that the `User Interface Design' component is in Bugzilla's `Browser' product for the same reason as `Browser-General', `Build Config', `Chatzilla', `Editor', and all the XP Toolkit components are. Not because they're specific to the browser, but because we don't yet have a `General' or `Communicator' product in Bugzilla. I have several other bugs which apply just to mail/news, and lots which apply both to mail/news and the browser. Anyway. There is no need to be able to turn this off, because you do not need to wait until a message is marked as read before deleting it. In fact, the delay would make it easier to distinguish between read and unread messages in your Trash folder, since they wouldn't automatically be marked as read when you deleted them one at a time. And as for the Outlook Express prefs which Henrik attached, I find it difficult to take seriously any prefs UI which simultaneously manages to (a) use multiple rows of tabs (yuk) and (b) not have room for something as basic as font selection in the main dialog.
So, mpt, how do you think the user should be able to set the specified time for which a message can be read without actually marking it read?
I agree with mpt on this one. I don't think a visible pref to set the amount of time before a message is marked as read is necessary. We should pick a reasonable amount of time, such as 2 seconds, and go with that. The user can still do anything to the message during this time, read it, move it, delete it, etc. What about a hidden pref for more experienced users?
i'm not arguing for a visible pref, but i do support a backend pref. mpt: jglick should at least be CC on these bugs, and IMO jglick should own them while the UI people (which may include you) make a decision. As for the fonts button, that opens a standard font picker dialog which is much more flexible than reinventing the wheel w/ only a fraction of the functionality. I'm not saying it's a good idea, but you'd be complaining if they did anything else too.
Actually, I prefer the Netscape school of "if clicked than read" school to the Outlook Express "click and wait, because we are nor sure you mean it". So if you want to change the behavior known to Netscape users for years you *need to* make a pref for restoring it.
True. But note that the original report correctly states that this is only a problem when scrolling past the message *with the arrow keys*. If you click on a message with the mouse, it's a pretty safe bet that you really did want to mark the message as read. So, how hard would it be to make this delay apply only when the message was navigated to via the keyboard, and not when it was selected with the mouse?
Depends on: 89458
*** Bug 89458 has been marked as a duplicate of this bug. ***
Hakan: this bug now depends on its duplicate. Certainly, something is wrong.
*** Bug 108537 has been marked as a duplicate of this bug. ***
Removing bogus dependency on a dupe.
No longer depends on: 89458
There needs to be, at the least, a toggle for turning off this "feature" of automatically marking messages read. I don't expect a message to be marked in any way until I mark it. Just because it is highlighted or on the screen doesn't mean I am looking at it and able to respond to it at that moment.
I too would request option to disable automatic marking as read. A while ago I moved to Mozilla from OE and this automatic "mark as read" is very annoying for me. Just as Nathaniel said, many times when I check the mail I may glance at the contents of mail but still want it to stay marked as unread until I decide otherwise. Currently I have to waste time making sure if it stayed marked unread. GUI option would be nice, but I'd settle for a hidden pref or even a workaround.
I noticed that I can't use autorepeat with an arrow key without it marking the current message read. This is because it takes a second of holding down the key before auto repeat starts.
Can anyone give me some clues as to where I should start looking if I want to fix this bug? I have the source code and am currently running binaries I compiled myself, which is a (poor) start.
*** Bug 141332 has been marked as a duplicate of this bug. ***
Today I installed a NN7.01 to my friend and had also discovered this "feature". Very annoyng. This had stopped me to moving from The Bat! to Mozilla. I believe the value should be editable by the user (even with hidden pref), just like it is in The Bat! (http://www.ritlabs.com/the_bat/). Just my 2 copeck (russian money) :).
I feel there should be a pref to vary the time delay before a message is marked as read. Mozilla is setup to toggle read/unread using the "read" column of the message headers but I still prefer the delay and the ability to turn off "automatic read" completely like in outlook.
I would like to have the delay be a preference so that I can set it to infinite. I get lots of email and so despite my best efforts, my Inbox has 5000 messages in it. The way I normally read mail is to start in sort by "unread", most recent first. When new mail arrives, it appears at the top of the index and I can see the subject without touching the computer. After I get lots of mail and decide to process some of it, I can switch to sort by "thread" and then process the unread threads using "n", or next unread message. When I realize that I want to process a message later, a common case, I have to specifically mark it "unread". It is this step that I want to eliminate, since I prefer to perform an action to process the message instead, such as mark a message "read", delete it, or move it. Later, I decide to do some work and so I then switch the index back to sort by "unread" and the cycle repeats.
i concur, this is how i use mail as well, i would very much like to disable the auto mark as read feature...
Ok I went for a witch hunt but didn't accomplish much :/ Pressing the F key triggers nextMsgCmd.key from: /mozilla/mailnews/base/resources/content/mailWindowOverlay.xul which executes goDoCommand('cmd_nextMsg'), triggering MsgNextMessage() from: /mozilla/mailnews/base/resources/content/mail3PaneWindowCommands.js which executes GoNextMessage(nsMsgNavigationType.nextMessage, false ); from: /mozilla/mailnews/base/resources/content/msgViewNavigation.js which executes ScrollToMessage(type, false, true); in the same file which executes gDBView.viewNavigate(type, resultId, resultIndex, threadIndex, true); in the same function and treeSelection.select(resultIndex.value); which is treeView.selection while treeView = gDBView.QueryInterface(Components.interfaces.nsITreeView); gDBView is probably created in: /mozilla/mailnews/base/resources/content/commandglue.js gDBView = Components.classes[dbviewContractId].createInstance(Components.interfaces.nsIMsgDBView); Now I'm lost and without a clue where to look. Nowhere seems to be code that says if msg changed then mark previous read. Most of the mailnews related magic seems to rely in: /mozilla/mailnews/base/src/nsMsgDBView.cpp Please, anyone with a real clue on how this mailnews ticks at least give us a estimate how much work would it take to disable the auto mark as read if pref controlled option is not possible at this time. Maybe mail3|mail6, helpwanted keywords would be fitting.
Well, in Eudora, you have an option to say if you want mails to be marked as read automatically when previewed and you can specify a delay for this. I would then suggest to modify the options from comment #3 into something like this: [ ] Automatically mark messages as read when previewed [ ] Wait for __ seconds before doing so. Having both options selected and 0 seconds would be like the current behaviour. About shortcuts, Mozilla already has a mouse shortcut: the green sun or diamond. If you click on it, you just toggle the read/unread status. It seems that we miss a keyboard chortcut for this: SHIFT+SPACE is the shortcut used in Eudora. We don't have to take the same one but it should definitely be an easy one.
Instead of adding a pref, why not make it so that middle-clicking (or shift-clicking) or some other modified click previews (ie displays) a message without ever setting it as read.
That wouldn't work because messages are selected for preview automatically. Take a look at this situation: * unread1 >- read1 * unread2 assume ">" indicates the highlighted message and "*" indicates an unread message. If you delete read1, the highlighted message then immediately becomes unread1 which is immediately marked as read.
This showld ve an pref since I want it as "not read" for 5 sec, someone else prefer for some longer time - the time is taken to read it thrue and deside should it be as "unread" for further desition or it should be as read since it's not worth for spendind time. My 2 copecks.
I also realized that messages get marked as readwhen you just want to drag and drop them from one mailbox to another. That should not be the case, of course.
*** Bug 198353 has been marked as a duplicate of this bug. ***
I would like to add my voice the many who have spoken in favor of some how some way being able to turn this "auto mark as read" feature OFF. I don't want a message to be marked as read until i do actually read the whole thing and deal with it. Often I will scann my incoming messages deal with the important ones, and get to the less important ones later. I know i can hit M to mark as unread again, but Eudora and Outlook/Express have the capability to turn it off, so should the bull. It is the one feature that is preventing me from early adopting this program as my email browser, give me some way to turn it off, and I'l use it. badger
Cmon guys, let's get this fixed in 1.4 please. It can't even be that hard. This is one of the biggest shortcomings of the mail client IMO. Get this fixed please.
*** Bug 202176 has been marked as a duplicate of this bug. ***
*** Bug 210820 has been marked as a duplicate of this bug. ***
*** Bug 195294 has been marked as a duplicate of this bug. ***
*** Bug 206644 has been marked as a duplicate of this bug. ***
*** Bug 195297 has been marked as a duplicate of this bug. ***
Any idea when this bug will be addressed, it is the only thing keeping me from switching to Thunderbird/Mozilla mail. If this is not slated to be addressed in the near future, I'll probably have to buy the Bat and just forget about this one. I only want to make one email switch, so I have to be sure its the one I want. badger
FYI, more hints in this n.p.m.mail-news post by David Fraser in 2003-03-03: http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=3E634B56.7020804%40sjsoft.com
Please build this feature in. Currently the mail client is unable to use. When deleting a message, the next is marked as read. I mean there is no usability. The best would be if mails were only marked as read when they are opened with a dubbleclick or by hitting the green dot. Please guys do this with the next version. Now i cannot use the client. It's a pity.
.
Assignee: jglick → sspitzer
*** Bug 215586 has been marked as a duplicate of this bug. ***
Can we mark this as target milestone 1.6a? Also, please everyone that is on this bug vote for it if you whould like to see this happen!
I'd vote for it twice if I could. This is the biggest issue holding me back from adopting this.. I've had it with Eudora, The Bat! is too quirky, and I want that Bayesian filtering.
I agree with comment #44: I don't want the mail marked read unless I cause it to open in a separate window.
Blocks: majorbugs
Is there any way to figure out when this bug will be addressed? Is it on anyones plate? Or are there steps to work around this bug?
I'm not sure how the mail/news bugs are being dealth with after the breakup of Firebird and Thunderbird. One workaround that I have been using that solves 98% of the problem is to make a custom view called "unread and recent", which displays only messages where "STATUS isn't READ" or "AGE IN DAYS is less than 2". This prevents recent messages from spontaneously disappearing from my inbox before I even know they exist, since everything will show up for at least 2 days.
I am trying a temp. solution for this issue with following script I can toggle the state of mail after 5 seconds if the user is still at the same mail GetThreadTree().parentNode.addEventListener('select', function(){setTimeout ('if (GetThreadTree().treeBoxObject.selection.currentIndex== ' +GetThreadTree().treeBoxObject.selection.currentIndex + ')goDoCommand(\'cmd_markAsRead\');',10)},true); GetThreadTree().parentNode.addEventListener('select', function(){ setTimeout ('if (GetThreadTree().treeBoxObject.selection.currentIndex == ' +GetThreadTree().treeBoxObject.selection.currentIndex + ')goDoCommand(\'cmd_markAsRead\');',5000)},true); But i need to do this only when the Mail status was unread Current issue How can check status of a mail (Read or Not) if i know position in the list. I can get Current position by GetThreadTree().treeBoxObject.selection.currentIndex
Following macro is work arround for this issue GetThreadTree().parentNode.addEventListener('select', function(){if(!SelectedMessagesAreRead()) setTimeout ('if (GetThreadTree().treeBoxObject.selection.currentIndex== '+GetThreadTree().treeBoxObject.selection.currentIndex +') MarkSelectedMessagesRead(false);',100)},true); you can get macroeditor at http://macroeditor.mozdev.org/ Or following extention (both Mozilla/Thunderbird) will do the trick http://downloads.mozdev.org/quicktools/QuickToolsKeepAsUnRead.xpi (now availble at us server, Pl. allow some time get downloads at other mirrors)
following ext will keep mail unread for ever http://downloads.mozdev.org/quicktools/QuickToolsKeepAsUnReadEver.xpi
Fantastic... Thanks ever so much. This should hold us over until they actually fix this bug.
Enormous Thanks! This bug turned out to be a major show stopper during a large Outlook to Mozilla conversion for me. This fix will keep the whole project live. Showing the CEO how Open Source can solve his problem is worth its weight in gold, irrespective to actually fixing the bug. Again... Thanks!
This should be under USER CONTROL, programmer should NOT determine what "a short while" is.
modified http://downloads.mozdev.org/quicktools/QuickToolsKeepAsUnRead.xpi (allow some time before download) - add preference "mailnews.messageread.delay" = 0 keep unread for ever > 0 that many seconds before making it read no GUI so use http://preferential.mozdev.org/ to change value default value is 10 seconds
A message's state should be managed by the user, not the mailclient. Every other mail client on earth (Evolution, Mulberry, OE, etc) supports this. C'mon now. Requiring an extension to invote a basic function is kind of silly.
The kind-of-fix in Comment #58 works, but it clears the Message Status, so that rather than 'New', a message shows no status ('Status' column is empty). This is kind of a drag.
> The kind-of-fix in Comment #58 works, but it clears the Message Status, > so that rather than 'New', a message shows no status > ('Status' column is empty). This is kind of a drag. Anybody know how fix it?
Just passing through... Here is a partial patch that would make this happen for thunderbird. We mark the message as read once in JS where the timer stuff is easier to manage instead of doing it separately down in each mail protocol after downloading a message. We put the prefs option for this under Thunderbird Advanced. Work that would still have to be done before we would take this: 1) Need to figure out when to clear the timer to mark the message as read when focus shifts away from the selected message. i.e. if you switch a folder, we should cancel the timer, if you move focus to another window I guess we should kill the timer. This will be pretty tricky unless we can come up with a dumb simple rule which tells us when to clear the timer and not let it file. 2) IMAP! Currently the message fetch action on the imap connection automatically causes the message to be marked as read on the server. This cuts down on traffic between the client and the server since the server can just mark it immediately after the fetch. If this preference is set to use a delay, we want to use the PEEK command to fetch the message instead of the way we do it today. This would keep the message from automatically getting marked as read on the server.
More functional patch. I plan on putting this patch in the next Thunderbird weekly build as a test to see how this shakes out.
Attachment #135434 - Attachment is obsolete: true
taking
Assignee: sspitzer → mscott
Tested patch in 2003-11-19 Thunderbird branch. Seems to work great, including in IMAP folders, and behaves correctly with multi selections. Does not appear to pause/reset the timer when the mail app or selected message loses focus, but this is very trivial. -- Thanks!
Thunderbird 0.4a (20031119) - works well. Since I didn't want to reinstall/reconfigure from scratch, I had to remove my old profile's chrome dir, since I had the old KeepAsUnread extension loaded. Application Data\Thunderbird\Profiles\default\xxxxxxx.yyy\chrome I then enabled the "Mark message as read after" option in the preferences and had to set a value of '9999' to get it to work properly. But it does what I need it to. Leaving the "Mark message as read after" option unchecked caused TB to mark the message as read immediately.
So in other words, "unchecked" is the same as "checked with a value of zero." I'm guessing that with the way the option is worded, it would seem more logical to interpret "unchecked" as "checked with a value of +Infinity." Minor nit, easy workaround, shouldn't IMHO block the patch going in.
I'm using IMAP with Mozilla Thunderbird from 2003-11-19 and I see a bug when using the keyboard to navigate/select messages. If I have several unread messages. Select 1 and wait till it is loaded then I hold down shift and press up a few times to do multiple selection. It seems the timer is not canceled and the message that is the lead item in the message list will be marked as read. Shouldn't the message pane be cleared when 2 or more messages is selected? If that is done I think the timer will be cleared as well.
The lastest build (2003-11-19) has an implementation of the delayed mark as read feature. The release notes say "To try this out, go to Tools / Options / Advanced / General Settings.". Well, I really would like to do so, but my Linux build (2003-11-21 GTK2) does not have such a menu entry. I see Tools / Options /Advanced of course, but I only have five entries in there: - Privacy - Passwords - Email Address Collection - Return Receipts - Connection Does the Linux build not have the settings? How can I set the setting to 5 seconds delay manually in the prefs.js?
Some user builds from mozillazine forums didn't have it either, try different ones, and/or: user_pref("mailnews.mark_message_read.delay", true); user_pref("mailnews.mark_message_read.delay.interval", 5);
this is only available in the windows build that I made because the patch is not checked into the source tree yet.
To remove my extension ( Comment #53 ) "Quick Tools - Keep Message as Unread" (for-ever or for-a-while options) you need only to delete/rename "QuickToolsKeepAsUnRead.jar" in the personal/application chrome dir TIA Biju
Blocks: 228788
I would also suggest to enable a context menu command that will allow message/s to be marked as unread. IMHO, the implementation in OE with the delay checkbox is very good: 1. Allow the user to uncheck the box to request that all messages remain unread until they are actually opened (i.e., double-click). As Scott said, this requires the use of PEEK instead of FETCH, not only because of performance issues but also because it will prevent the flashing effect that is visible when using the QuickToolsKeepAsUnRead extension. 2. Allow the user to check that box and specify how much time to wait before marking as unread. The message should be marked as UNREAD if the user stayed on that message for the specified time (i.e., any move to a different msg/folder should clear the timer). 3. Allow messages to be individually marked as read/unread
Comment on attachment 138499 [details] [diff] [review] updated patch for seamonkey and tbird [Checked in: Comment 85] Time to get these thunderbird fixes landed on the trunk. Thunderbird shipped with this feature back in 0.4 and it's been present in the tbird build since early November and so far I have not heard of any regressions. The biggest change removes all of the places we used to mark a message as read after we loaded it for each protocol. We now just mark it read from the UI after we have loaded a message in the message pane. The second phase of the change was to make that JS call smart enough to fire on a timer if configured to do so.
Attachment #138499 - Flags: superreview?(bienvenu)
Comment on attachment 138499 [details] [diff] [review] updated patch for seamonkey and tbird [Checked in: Comment 85] sr=bienvenu, with one nit: +++ mailnews/imap/src/nsImapMailFolder.cpp 18 Dec 2003 19:57:15 -0000 @@ -3771,17 +3771,6 @@ nsCOMPtr<nsIMsgDBHdr> msgHdr; m_curMsgUid = uidOfMessage; res = GetMessageHeader(m_curMsgUid, getter_AddRefs(msgHdr)); I don't think you need to GetMessageHeader here, since you don't use it. so this line and the decl for msgHdr could be removed as well.
Attachment #138499 - Flags: superreview?(bienvenu) → superreview+
Comment on attachment 138499 [details] [diff] [review] updated patch for seamonkey and tbird [Checked in: Comment 85] >+function MarkCurrentMessageAsRead() >+{ >+ var msgURI = GetLoadedMessage(); >+ >+ if (msgURI) >+ { >+ var msgService = messenger.messageServiceFromURI(msgURI); >+ if (msgService) >+ { >+ var msgHdr = msgService.messageURIToMsgHdr(msgURI); >+ >+ if (msgHdr) >+ { >+ var headers = Components.classes["@mozilla.org/supports-array;1"].createInstance( Components.interfaces.nsISupportsArray ); >+ headers.AppendElement( msgHdr ); >+ msgHdr.folder.markMessagesRead(headers, true); >+ } >+ } >+ } >+} Can't you use gDBView.doCommand(nsMsgViewCommandType.markMessagesRead) here?
*** Bug 230296 has been marked as a duplicate of this bug. ***
Since possibly the 01/06 partial checkin, my filters that delete or move mail and have "mark as read" are not really marking as read. They still appear unread. Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7a) Gecko/2004010704
nothing was checked in that should have any effect in the code, afaik. James, are you using POP3 or IMAP?
Using POP3. The only other bug that seems relaited (sort of) is http://bugzilla.mozilla.org/show_bug.cgi?id=227657 I'm still testing with clean installs - repeatable. Maybe I need to cut a diff bug. Steps: Send email to POP acct, have filter to move mail to some other folder and have set "mark as read". Mail moves and still appears as unread. I'm going backwards in creature snapshots to see when it changed on me.
Something changed from 010608 to 010709. From 010608 and earlier, filtering mail with "marked as read" worked. I wasn't sure if this bug or something similar might have touched this. thx
please file a new bug. It has nothing to do with this. I have not checked this in yet.
I'm pretty sure I know what broke this (if it broke yesterday). I'll file a new bug and we can move the discussion there.
Checked in for seamonkey and thunderbird. I included David and Neil's feedback (thanks for the tip Neil). The prefs that control this feature are: mailnews.mark_message_read.delay.interval and mailnews.mark_message_read.delay our default behavior does not change, mark_message_read.delay defaults to false. the default interval length is 5 seconds
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
What if you wanted to *always* keep the message unread until the user took an explict action to mark it read? What values does one set for the prefs? mailnews.mark_message_read.delay.interval and mailnews.mark_message_read.delay Can you set delay=true and delay.interval=0?
Scott, Status should not have changed to "RESOLVED" Because user still dont have an "EASY" option to "Keep mail as Unread for ever" work around keep delay as 999999999 sec, ie 31 years According to me, wordings in Tools\Options\Advanced\General Settings. (I may be wrong my english not good) "Mark message read after displaying for [xxx] second(s)" can be read as "Mark message read after displaying (for [xxx] seconds)" so if it is unchecked mail should never marked as read. Then I feel wording should be changed as "Automatically mark message as read after previewing (for [xxx] seconds)"
I agree with Biju and it directly relates to the first attachment for this bug that shows the Outlook Express option that implements this logic. As I wrote in comment#73, I think it can be very helpful to also have a context menu command to mark messages as UNREAD.
Attachment #138499 - Attachment description: updated patch for seamonkey and tbird → updated patch for seamonkey and tbird [Checked in: Comment 85]
Attachment #138499 - Attachment is obsolete: true
Comment on attachment 138499 [details] [diff] [review] updated patch for seamonkey and tbird [Checked in: Comment 85] This added a Build Warning in <http://tinderbox.mozilla.org/SeaMonkey/warn1073635800.20251.html#scott>: { 2. mailnews/imap/src/nsImapService.cpp:564 (See build log excerpt) Enumeral mismatch in conditional expression: `nsIImapUrl::' vs `nsIImapUrl::' 562 prefBranch->GetBoolPref("mailnews.mark_message_read.delay", &forcePeek); 563 564 rv = FetchMessage(imapUrl, forcePeek ? nsIImapUrl::nsImapMsgFetchPeek : nsIImapUrl::nsImapMsgFetch, folder, imapMessageSink, 565 aMsgWindow, aDisplayConsumer, msgKey, PR_FALSE, (mPrintingOperation) ? "print" : nsnull, aURL); 566 } } It looks like a "bogus" warning, but I'd like to have your insights on this/such warning(s). Thanks.
it is a bogus warning. Someone would need to fix xpidl so that all constants in an interface are part of the same enum. (or add an enum type to idl which behaves like this.)
bug 231428 is for the UI
*** Bug 243634 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
*** Bug 279580 has been marked as a duplicate of this bug. ***
No longer blocks: majorbugs
Attachment #138499 - Attachment is obsolete: false
*** Bug 100246 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: