There are a number of trade-offs at work here, so I don't really see this bug getting fixed. I am subscribing Stuart, since he worked on this notification code.
When you post a form on Launchpad, we reply with a redirect to another page. This is done because hitting the reload button on a page that results from a POST will prompt the user to repost the data, which could then result in duplicate comments, bugs, etc. Lots of people do hit the reload button and few read the dialog (developers and users alike), so the post-then-redirect behaviour is required.
So the page where you see the notification is not being served by the request that set the notification. The notifications are handled through the session cookie. As cookies are handled on a per-instance basis rather than per-window or tab, all the windows you have open share the same session. In this case, the POST requests for the two bugs filed would have been processed creating the notifications, then the first window that issued the subsequent GET picked up the two notifications.
We used to solve this problem by appending a query parameter, but changed to the current implementation due to complaints about the ugly URLs (see bug 5412).
There are a number of trade-offs at work here, so I don't really see this bug getting fixed. I am subscribing Stuart, since he worked on this notification code.
When you post a form on Launchpad, we reply with a redirect to another page. This is done because hitting the reload button on a page that results from a POST will prompt the user to repost the data, which could then result in duplicate comments, bugs, etc. Lots of people do hit the reload button and few read the dialog (developers and users alike), so the post-then-redirect behaviour is required.
So the page where you see the notification is not being served by the request that set the notification. The notifications are handled through the session cookie. As cookies are handled on a per-instance basis rather than per-window or tab, all the windows you have open share the same session. In this case, the POST requests for the two bugs filed would have been processed creating the notifications, then the first window that issued the subsequent GET picked up the two notifications.
We used to solve this problem by appending a query parameter, but changed to the current implementation due to complaints about the ugly URLs (see bug 5412).