133527 - [patch] New mail notification "banner" at wrong place (always pops up at bottom right hand corner)

Status: RESOLVED FIXED

(Core :: Widget: Win32, defect)

Description

[Jens Bäckman]

BuildID:    2002032503

The new mail notification system doesn't just display a small icon in the tray,
it animates a window telling me about this too. The effect should probably be
that it peeks up from the Start bar or system tray. Unfortunately, if you have
moved the Start bar somewhere else than the default, it doesn't work.

Steps to Reproduce:
1. Move the Start bar to the top of the screen.
2. Wait for some mail to arrive.
3. Look at the notification window appearing out of thin air.

Comment 1

[Jens Bäckman]

Attachment: Small shot of my lower-right desktop and the banner

Comment 2

[grylchan]

Reassigning to mscott and taking seth off list..

Using 2002032503 commercial trunk on NT 4.0
The reporter is correct. If I move the start bar to top
or left/right hand side of the monitor, the result
is new mail notification banner will always appear
in bottom right hand corner.

I know there internationalization bug sorta of similar: bug 132733

I'll let mscott decide if this valid or not..

Comment 3

[Ryan Pertusio]

Attachment: MSN Messenger mail alert from bottom left of screen

Although the intention is not necessarily to 'copy' what MSN Messenger does, I
provide this attachment for comparasin.

I moved the taskbar to the left side of my screen (making it vertical).
Mozilla should (IMHO) do something like MSN Messenger does, shown in the
attachment.  The alert pops up nearest to the 'system tray'.

Comment 4

[Alfonso Martinez]

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

Comment 5

[Olga]

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

Comment 6

[grylchan]

marking as new

Comment 7

[R.K.Aa.]

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

Comment 8

[Frank Burleigh]

I do not believe that 137781 is a dup of this.  137781 is about the animated
notification not accounting for a task (start) bar with autohide ON, not about
the placement of the task (start) bar.  However, since someone has swept 137781
away I'll note the point here.

Comment 9

[R.K.Aa.]

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

Comment 10

[:deanis74]

The alert is hard-coded to display at the bottom-right of the window.  See
http://lxr.mozilla.org/seamonkey/source/xpfe/components/alerts/resources/content/alert.js#89

 88   // be sure to offset the alert by 10 pixels from the far right edge of the
screen
 89   window.moveTo( (screen.availLeft + screen.availWidth - window.outerWidth)
- 10, screen.availTop + screen.availHeight - window.outerHeight);

This should use the position of the system tray, which can be determined by
finding and measuring the window with a class of "Shell_TrayWnd".  There's a
more in-depth example (I only just found it, I haven't looked at it in-depth),
which takes into account third-party shells, at
http://www.codeproject.com/shell/trayposition.asp.

Comment 11

[Richard Hurt]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040803 Firefox/0.9.3

I can confirm this bug still exists on WinXP SP1.  Additionally, this is a
systemwide bug as it also happens with the download notification pop-up.  My
Start bar is auto-hide at the top of the screen, yet my "All Downloads Complete"
messages appear in the bottom right corner.

Thanx!
  Richard

Comment 12

[Jens Bannmann]

Taking; Patch coming up.

Comment 13

[Jens Bannmann]

Attachment: auto-detect alert origin

This patch uses the ABM_GETTASKBARPOS message to detect the screen edge the
task bar is docked to, and passes the appropriate alert origin to the
cross-platform alert animation code. Other platforms can hook into this, too,
and use their own ways of determining the correct origin.

If the task bar position couldn't be determined or there is no code to do so
(e.g. Linux), the code will default to the lower right corner.

When the task bar is on the left or right side, we obviously don't want a wide
alert, but one that looks a bit more like attachment 76370 [details] (laid out
vertically). The new code adjusts the orientation of the box that contains the
icon and text accordingly, but this needs some CSS to make it look really good
(margins etc.)

Comment 14

[Jens Bannmann]

Note: this is a toolkit patch, affecting Firefox and Thunderbird. I'll port the
changes to SeaMonkey once this is reviewed.

Comment 15

[Jens Bannmann]

Attachment: auto-detect alert origin, v2

Now includes CSS fixes to make it look good. Screenshots following.

Comment 16

[Jens Bannmann]

Attachment: alert sliding in horizontally, from bottom-left corner

Comment 17

[Jens Bannmann]

Attachment: alert sliding in vertically, from top-right corner

Comment 18

[Jens Bannmann]

Comment on attachment 198835 [details] [diff] [review]
auto-detect alert origin, v2

Benjamin, do you have time to review this?

Comment 19

[Jens Bannmann]

Note: the comment in the patch regarding a reflow problem refers to a wrong bug
number, the correct one is bug 311557.

Comment 20

[Jens Bannmann]

Attachment: auto-detect alert origin, v3

Revised version including theme changes for qute and some polishing.

Comment 21

[Benjamin Smedberg]

Comment on attachment 199016 [details] [diff] [review]
auto-detect alert origin, v3

-.alertImageBox {
+.alertBox[orient="horizontal"] .alertImageBox {

Descendent selectors perform pretty poorly: please come up with a way to use
child selectors here and in the matching places in this patch.

Comment 22

[Jens Bannmann]

Attachment: auto-detect alert origin, v4

Now uses child selectors.

Benjamin, this patch also includes the following lines from a patch to bug
310900:
| // work around a bug where sizeToContent() leaves a border outside of the
content
|  var contentDim = alertBox.boxObject;
|  if (window.innerWidth == contentDim.width + 1)
|    --window.innerWidth;
They're not really neccessary for this bug. Should I leave them out, or
consider them r+ as part of this patch?

Comment 23

[Benjamin Smedberg]

Comment on attachment 199186 [details] [diff] [review]
auto-detect alert origin, v4

Please keep the outerwidth bug separate, I'm not sure I particularly like the
hack being perpetrated ;-)

Comment 24

[Jens Bannmann]

Attachment: auto-detect alert origin, v5

Removing that workaround and carrying over r=bsmedberg.

Comment 25

[Jens Bannmann]

Comment on attachment 199320 [details] [diff] [review]
auto-detect alert origin, v5

I changed my mind on this patch. It would be way cleaner to put the
Windows-specific code into nsLookAndFeel, where each widget set can
independently implement it without further complicating the alerts service.
I'll provide a new patch these days.

Comment 26

[Jens Bannmann]

I did some tests with two monitors. It seems Windows lets you place the task bar
only at the outer edges of the virtual (combined) screen, spanning two screens
or one, depending on their position. Therefore, the API call I use to detect the
screen edge isn't affected at all (i.e. doesn't need to be per-screen) - it
reports the task bar position correctly, just relative to the virtual screen.
The coordinates calculated by the alert notification window also refer to the
virtual screen, which makes it come up correctly. (Current releases always use
the lower-right corner of the virtual screen)

Summarized: the alert origin stuff automatically does the right thing for
multiple monitors.

Comment 27

[Jens Bannmann]

Attachment: auto-detect alert origin, v6

Moved Windows-specific code into the look and feel implementation.

Comment 28

[Jens Bannmann]

Attachment: auto-detect alert origin, v7

Made some code cleanup and robustness improvements suggested by timeless.

Comment 29

[Jens Bannmann]

Comment on attachment 199588 [details] [diff] [review]
auto-detect alert origin, v7

After a bit of reorganization, this patch now touches widget/public and
widget/src/windows. Neil, can you r/sr both?

Comment 30

[[e-mail]]

You ought to get someone else to look at this too.

Skimming the code, it looks ok, although I don't like your handling of the alert
positions, so it's difficult to see if they're correct without testing. Would it
by any chance be possible to define "0" as bottom right vertical, and use bits
to toggle between horizontal/vertical, left/right, top/bottom? e.g.
+  if (gOrigin & HORIZONTAL)
+  {
+    gFinalSize = window.outerWidth;
+    window.outerWidth = gCurrentSize;
+  }
+  else
+  {
+    gFinalSize = window.outerHeight;
+    window.outerHeight = gCurrentSize;
+  }
+
+  var x = gOrigin & LEFT ? screen.availLeft :
+          screen.availLeft + screen.availWidth - window.outerWidth;
+  var y = gOrigin & TOP ? screen.availTop :
+          screen.availTop + screen.availHeight - window.outerHeight;
(I leave it to you to choose which of 1, 2 and 4 are TOP, LEFT and HORIZONTAL)

Comment 31

[[e-mail]]

Comment on attachment 199588 [details] [diff] [review]
auto-detect alert origin, v7

Please try this layout:
*       6       4
*     +-----------+
*    7|           |5
*     |           |
*    3|           |1
*     +-----------+
*       2       0

Comment 32

[Jens Bannmann]

Attachment: auto-detect alert origin, v8

Neil: I refactored the alert origin values to be a bit field, like you proposed. It works fine and really looks clearer. I'm unsure about one thing, though: should I actually define those constants on the C++ side, and if so, how (#define in nsILookAndFeel.h, some kind of interface member)? For JS, I just defined them as constants at the top of the file. Let me know what you think.

Comment 33

[Jens Bannmann]

Comment on attachment 226056 [details] [diff] [review]
auto-detect alert origin, v8

>+     * Use any combination of these bits: VERTICAL (1), LEFT (2), TOP (4).

should be

>+     * Use any combination of these bits: HORIZONTAL (1), LEFT (2), TOP (4).

Comment 34

[Jens Bannmann]

Morphing to a Thunderbird bug so I can request the blocking flag.

Comment 35

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 226056 [details] [diff] [review]
auto-detect alert origin, v8

widget/src/windows/nsLookAndFeel.cpp

+//typedef BOOL (WINAPI * GetSpecialPathProc) (HWND hwndOwner, LPSTR lpszPath, int nFolder, BOOL fCreate);

what's this line for?


MSDN says:
You must specify the cbSize and hWnd when sending this message; all other members are ignored.

So, you need a HWND.

+     * Use any combination of these bits: VERTICAL (1), LEFT (2), TOP (4).

It might be good to actually declare those as constants somewhere, and use bitwise ORs of the flags

Comment 36

[Jens Bannmann]

Attachment: auto-detect alert origin, v9

Addressing biesi's review comments:
- Removed unnecessary //typedef line
- Specifying the HWND of the task bar.
- Defined constants for the bit field values in nsILookAndFeel.h, using them in windows/nsLookAndFeel.cpp and in JS (redeclared there as const).
- Removed some tabs that crept into the previous patch

Comment 37

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 226651 [details] [diff] [review]
auto-detect alert origin, v9

+          CWnd *shellWindow = FindWindow("Shell_TrayWnd", NULL);
+          if (pwnd != NULL)


you can't use MFC here. also, what's pwnd?

I don't understand why this compiles... why can you assign a HWND to a CWnd*?

Comment 38

[Jens Bannmann]

Attachment: auto-detect alert origin, v10

You're right, that didn't really compile, sorry. I messed up my scripts and did not notice I was still seeing the previously compiled version.

This version actually compiles and works now, though I'm unsure whether the algorithm to get the task bar HWND is optimal.

Comment 39

[Jens Bannmann]

Comment on attachment 226911 [details] [diff] [review]
auto-detect alert origin, v10

>Index: widget/src/windows/nsLookAndFeel.cpp
>+          // Get task bar window handle
>+        	HWND hwnd = GetWindow(GetDesktopWindow(), GW_CHILD);
>+        	HWND shellWindow = NULL;
>+        	char classname[80];
>+        	while(hwnd)
>+        	{
>+        		GetClassName(hwnd, classname, 80);
>+        		if(lstrcmpi(classname, "Shell_TrayWnd") == 0)
>+        		{
>+        		  shellWindow = hwnd;
>+        		}
>+        		hwnd = GetWindow(hwnd, GW_HWNDNEXT);
>+        	}

I fixed the indentation (tabs -> spaces) here after creating the patch.

Comment 40

[Christian :Biesinger (don't email me, ping me on IRC)]

so this wouldn't work?
          HWND shellWindow = FindWindow("Shell_TrayWnd", NULL);

Comment 41

[Jens Bannmann]

Attachment: auto-detect alert origin, v11

(In reply to comment #40)
> so this wouldn't work?
>           HWND shellWindow = FindWindow("Shell_TrayWnd", NULL);

It does. Somehow I assumed that "you can't use MFC here" was referring to FindWindow() without actually verifying that. Further proof that I'm still not familiar with Windows programming at all...

Comment 42

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 226964 [details] [diff] [review]
auto-detect alert origin, v11

ah, sorry - that MFC comment referred to the CWnd type only.

r=biesi on the widget/ parts

a comment about toolkit/components/alerts/src/nsAlertsService.cpp though:
+    if (origin && origin >= 0 && origin <= 7)

0..7 are the only valid values, right? Why not make this an assertion? (In any case, the origin && part does not make much sense to me)

Comment 43

[:deanis74]

(In reply to comment #41)
> Created an attachment (id=226964) [edit]
> auto-detect alert origin, v11

Just sticking my nose in here.  Feel free to ignore me.

nsAlertsService.cpp:
+  if (NS_FAILED(rv)) return rv;

Could these be NS_ENSURESUCCESS instead?  Not sure if that's the purpose.  If not, the "return" should be on a new line.

+//  Bits for eMetric_AlertNotificationOrigin

There are only eight possibilities, right?  Why not just use eight defines and avoid all this confusion?  I don't understand how they work, and it seems that biesi doesn't, either.

Comment 44

[Jens Bannmann]

(In reply to comment #42)
> +    if (origin && origin >= 0 && origin <= 7)
> 0..7 are the only valid values, right? Why not make this an assertion? (In any
> case, the origin && part does not make much sense to me)

Yeah, I changed it accordingly. And the origin && part indeed does not make any sense, I removed it.


(In reply to comment #43)
> nsAlertsService.cpp:
> +  if (NS_FAILED(rv)) return rv;
> Could these be NS_ENSURESUCCESS instead?  Not sure if that's the purpose.

Yeah, that would be better.

> +//  Bits for eMetric_AlertNotificationOrigin
> 
> There are only eight possibilities, right?  Why not just use eight defines and
> avoid all this confusion?  I don't understand how they work, and it seems that
> biesi doesn't, either.

Eight distinct values was what I had in the v7 patch, and Neil suggested a bit field in comment 30 and comment 31. IMO using them (even as constants) would not make things easier, but worse. Besides Neil's point in the aforementioned comments, another drawback would be that it would complicate the if-conditions in the JS code (needing to check for 4 possible "upper" corners instead of checking for the TOP constant). Additionally, the code in dependent bug 341958 is not interested in the horizontal/vertical distinction, which is easier with the bit field. Furthermore, I can imagine future enhancements (like explicitly targeting different monitors etc) will be easier with a bit field.

Comment 45

[:deanis74]

(In reply to comment #44)
> Eight distinct values was what I had in the v7 patch, and Neil suggested a bit
> field in comment 30 and comment 31. IMO using them (even as constants) would
> not make things easier, but worse. Besides Neil's point in the aforementioned
> comments, another drawback would be that it would complicate the if-conditions
> in the JS code (needing to check for 4 possible "upper" corners instead of
> checking for the TOP constant). Additionally, the code in dependent bug 341958
> is not interested in the horizontal/vertical distinction, which is easier with
> the bit field. Furthermore, I can imagine future enhancements (like explicitly
> targeting different monitors etc) will be easier with a bit field.

Good points.  I guess it's just me.  What about more descriptive bits, then, or am I in fact making things more complicated rather than less?

NS_ALERT_POSITION_LEFT
NS_ALERT_POSITION_TOP
NS_ALERT_POSITION_RIGHT
NS_ALERT_POSITION_BOTTOM
NS_ALERT_SLIDE_HORIZONTAL
NS_ALERT_SLIDE_VERTICAL

Default = NS_ALERT_POSITION_RIGHT & NS_ALERT_POSITION_BOTTOM & NS_ALERT_SLIDE_VERTICAL

Comment 46

[:deanis74]

Then you could get rid of the fancy diagram in nsILookAndFeel.h, since the bits would be self-explanatory.

Comment 47

[[e-mail]]

Comment on attachment 226964 [details] [diff] [review]
auto-detect alert origin, v11

>+
>+
Nit: doubled blank line

>+          // Determine position
>+          if (shellWindow != NULL)
>+          {
Nit: that comment should be inside the block

>+              {
>+              case ABE_LEFT:
Nit: file style is two space indent for the case labels themselves

>+                  aMetric = NS_ALERT_HORIZONTAL + NS_ALERT_LEFT;
Nit: use | to combine bitmasks

>+              case ABE_BOTTOM:
>+                  aMetric = 0;
>+                  break;
Nit: aMetric is already 0

>+  if (NS_FAILED(rv)) return rv;
I'm happy with changing this to NS_ENSURE_SUCCESS(rv, rv) but otherwise you should have had the return on its own line.

>+  scriptableOrigin->SetData(0);
Nit: data is already 0

>+    if (origin && origin >= 0 && origin <= 7)
As biesi noticed, origin && is a bit silly. In fact, I think you should pass the entire PRInt16 value in case someone needs to extend it.

>+var gFinalSize = 50;
Nit: you don't actually use the 50, so you could drop the value.

>+var gOrigin = 0; // bottom right, sliding vertically
I think you should mention that this is just a default value.

>+  // for left/top positions, fix the contents at the edge facing the screen's center
>+  // so that the window looks like "sliding in" and not like "unfolding"
>+  if (gOrigin & NS_ALERT_TOP || gOrigin & NS_ALERT_LEFT)
I don't think this test is correct. It fails in the case of a vertical bottom left alert and a horizontal top right alert.

>+  {
>+    document.documentElement.setAttribute("pack", "end");
>+
>+    // the window defaults to vertical orientation, so we need to change it
>+    // when sliding horizontally so the packing works as intended
>+    if (gOrigin & NS_ALERT_HORIZONTAL)
>+    {
>+      document.documentElement.setAttribute("orient", "horizontal");
>+    }
>+  }
Again, this fails in the case of a horizontal bottom right alert. Try this:
if (gOrigin & NS_ALERT_HORIZONTAL) {
  document.documentElement.orient = "horizontal";
  if (gOrigin & NS_ALERT_LEFT)
    document.documentElement.pack = "end";
} else {
  if (gOrigin & NS_ALERT_TOP)
    document.documentElement.pack = "start";
}

>+  alertBox.setAttribute("orient", (gOrigin & NS_ALERT_HORIZONTAL) ? "vertical" : "horizontal");
Nits: alertBox.orient = gOrigin & NS_ALERT_HORIZONTAL ...
See nsIDOMXULElement.idl for the other shortcut properties I skipped.

>+  // Determine final size
>+  if (!(gOrigin & NS_ALERT_HORIZONTAL))
Nit: swap the blocks so you don't need the !()

>+  var x = gOrigin & NS_ALERT_LEFT ? screen.availLeft :
>+          (screen.availLeft + screen.availWidth - window.outerWidth);
>+  var y = gOrigin & NS_ALERT_TOP ? screen.availTop :
>+          (screen.availTop + screen.availHeight - window.outerHeight);
Nit: don't need the ()s

>+  if (!(gOrigin & NS_ALERT_LEFT) && !(gOrigin & NS_ALERT_HORIZONTAL))
Can be written !(gOrigin & (NS_ALERT_LEFT | NS_ALERT_HORIZONTAL))

>+  {
>+    // offset the alert by 10 pixels from the far right edge of the screen
>+    // (maintains the classic behaviour of the hardcoded lower-right position)
>+    x -= 10;
>+  }
I wonder whether we should offset the alert from other edges of the screen:
if (gOrigin & NS_ALERT_HORIZONTAL)
  y += gOrigin & NS_ALERT_LEFT ? 10 : -10;
else
  x += gOrigin & NS_ALERT_TOP ? 10 : -10;

Comment 48

[Jens Bannmann]

(In reply to comment #45)
> Good points.  I guess it's just me.  What about more descriptive bits, then,
> or am I in fact making things more complicated rather than less?

Yeah, probably. Having e.g. both a left and right constant would no longer make these two alternatives mutually exclusive :-(

Comment 49

[Jens Bannmann]

Attachment: auto-detect alert origin, v12

Carrying over r@widget=biesi and r@toolkit=bsmedberg (the latter from attachment #199186 [details] [diff] [review]).

Fixed all of Neil's comments and nits.

In particular, I added the offset for all edges of the screen, for consistency's sake. Note that the improved mail alert for Tb 2.0 no longer uses this offset, probably because it's larger. One could argue that both alerts service and mail alert should behave the same here, but unless someone makes that point, I'm fine with having the alerts service consistent just with itself.

Comment 50

[Mike Beltzner [:beltzner, not reading bugmail]]

--> beta2, shouldn't block firefox 2 beta1

Comment 51

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

If this doesn't get in to both the trunk and (then) the branch soon, it's probably not going to make Firefox 2.

Comment 52

[Mike Connor [:mconnor]]

Not going to block on this, will consider a patch if it appears soon enough.

Comment 53

[[e-mail]]

Comment on attachment 227310 [details] [diff] [review]
auto-detect alert origin, v12

>+              switch(appBarData.uEdge)
>+              {
>+                case ABE_LEFT:
>+                    aMetric = NS_ALERT_HORIZONTAL | NS_ALERT_LEFT;
>+                    break;
>+                case ABE_RIGHT:
>+                    aMetric = NS_ALERT_HORIZONTAL;
>+                    break;
>+                case ABE_TOP:
>+                    aMetric = NS_ALERT_TOP;
>+                    break;
>+                case ABE_BOTTOM:
>+                    break;
>+              }
Hmm, sometimes the code is indented 4 spaces under the case, sometimes 2.
I think I prefer 2, especially as it says so in the mode line ;-)

Comment 54

[Jens Bannmann]

Attachment: auto-detect alert origin, v13

Fixed the indentation. Thanks, Neil!

Carrying over r@widget=biesi, r@toolkit=bsmedberg and sr=neil.

Can someone check this in on on trunk?

Comment 55

[:Gavin Sharp [email: [e-mail]]]

mozilla/toolkit/themes/winstripe/global/alerts/alert.css 	1.5
mozilla/widget/public/nsILookAndFeel.h 	1.56
mozilla/widget/src/xpwidgets/nsXPLookAndFeel.cpp 	1.51
mozilla/widget/src/windows/nsLookAndFeel.cpp 	1.54
mozilla/toolkit/components/alerts/src/nsAlertsService.cpp 	1.6
mozilla/toolkit/components/alerts/resources/content/alert.xul 	1.8
mozilla/toolkit/components/alerts/resources/content/alert.js 	1.8
mozilla/toolkit/components/alerts/src/Makefile.in 	1.5

Comment 56

[Jens Bannmann]

FYI, I filed bug 345238 to port this to SeaMonkey.

Comment 57

[Jens Bannmann]

Comment on attachment 229835 [details] [diff] [review]
auto-detect alert origin, v13

- Has been on trunk since 2006-07-19, without regressions
- Change summary: introduces new value "eMetric_AlertNotificationOrigin" in nsILookAndFeel and implements it for Windows. Changes alerts service to use that value to determine alert position.
- Risk assessment: low for C++ code - the patch only adds new behaviour, and is small-sized. The (JS) alert code itself is changed considerably, but has no ties to other frontend code.
- L10N impact: no string changes.
- Alerts service API is unchanged.
- This bug used to block 1.8.1. mconnor said a patch would be considered though; here it is.
- Longstanding bug with high visibility for users with non-bottom-taskbars.

Comment 58

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 229835 [details] [diff] [review]
auto-detect alert origin, v13

Drivers feel like it's too late to be taking this change on the branch for Firefox2 at this stage in the game.

Comment 59

[Jens Bannmann]

Comment on attachment 229835 [details] [diff] [review]
auto-detect alert origin, v13

How about taking this for Thunderbird 2? Summary and risk assessment in comment #57.

Comment 60

[Daniel Veditz [:dveditz]]

Comment on attachment 229835 [details] [diff] [review]
auto-detect alert origin, v13

We're behind for 1.8.1.1 and don't need more risk, but we'll look at this before tbird2.

Comment 61

[Jay Patel [:jay]]

Comment on attachment 229835 [details] [diff] [review]
auto-detect alert origin, v13

Approved for 1.8 branch, a=jay for drivers.  Let's get this in for Thunderbird  2.

Comment 62

[Jens Bannmann]

Attachment: auto-detect alert origin [1.8 branch version]

Attaching new version of latest patch that applies to 1.8 branch; a=jay.

Gavin, could you check this in?

Comment 63

[:Gavin Sharp [email: [e-mail]]]

mozilla/toolkit/themes/winstripe/global/alerts/alert.css 	1.4.8.1
mozilla/toolkit/components/alerts/src/nsAlertsService.cpp 	1.5.8.1
mozilla/toolkit/components/alerts/src/Makefile.in 	1.4.8.1
mozilla/widget/public/nsILookAndFeel.h 	1.47.2.6
mozilla/toolkit/components/alerts/resources/content/alert.js 	1.4.10.4
mozilla/toolkit/components/alerts/resources/content/alert.xul 	1.6.10.2
mozilla/widget/src/xpwidgets/nsXPLookAndFeel.cpp 	1.44.2.3
mozilla/widget/src/windows/nsLookAndFeel.cpp 	1.50.2.4

Comment 64

[Marcia Knous [:marcia]]

verified fixed on the 1.8 branch using version 2 beta 1 (20070112). Adding keyword.