| 2007-08-08 20:36:19 |
Ian Jackson |
bug |
|
|
added bug |
| 2007-08-08 20:37:16 |
Ian Jackson |
bug |
|
|
added attachment 'weirdness.png' (screenshot of the strange results) |
| 2007-08-14 02:19:15 |
James Henstridge |
bug |
|
|
added subscriber Stuart Bishop |
| 2007-08-16 06:50:45 |
James Henstridge |
malone: status |
New |
Won't Fix |
|
| 2007-08-16 06:50:45 |
James Henstridge |
malone: statusexplanation |
|
Closing as per bug 132747 |
|
| 2007-11-29 22:27:55 |
Matthew Paul Thomas |
malone: importance |
Undecided |
Low |
|
| 2007-11-29 22:27:55 |
Matthew Paul Thomas |
malone: status |
Won't Fix |
Confirmed |
|
| 2008-08-06 11:52:53 |
Stuart Bishop |
launchpad: status |
Confirmed |
Won't Fix |
|
| 2008-08-06 11:52:53 |
Stuart Bishop |
launchpad: statusexplanation |
Reproduced in bug 172688. Reopening because Robert Collins says there's a way to fix this without using URL parameters. |
Setting to Won't Fix until someone can come up with a way to identify if a notification should display in the current window that doesn't violate our other requirements (such as not passing a token in the URL, which is how we where originally doing this without the race condition) |
|
| 2008-08-07 00:13:44 |
Martin Pool |
launchpad: status |
Won't Fix |
Confirmed |
|
| 2008-08-07 00:13:44 |
Martin Pool |
launchpad: importance |
Low |
Undecided |
|
| 2008-08-07 00:13:44 |
Martin Pool |
launchpad: statusexplanation |
Setting to Won't Fix until someone can come up with a way to identify if a notification should display in the current window that doesn't violate our other requirements (such as not passing a token in the URL, which is how we where originally doing this without the race condition) |
reopening as there are some plausible ways to fix it |
|
| 2009-01-14 18:17:43 |
Matthew Paul Thomas |
title |
thank you for your bug report appears in wrong window |
Notification (e.g. "Thank you for your bug report") appears in wrong window |
|
| 2010-06-25 22:48:10 |
Curtis Hovey |
launchpad-foundations: status |
Confirmed |
Triaged |
|
| 2010-06-25 22:48:13 |
Curtis Hovey |
launchpad-foundations: importance |
Undecided |
Low |
|
| 2011-05-10 08:28:19 |
Robert Collins |
launchpad: importance |
Low |
High |
|
| 2011-05-10 08:28:22 |
Robert Collins |
description |
I just submitted two bug reports against the same package in Ubuntu nearly simultaneously. I did this using firefox from a slightly out-of-date gutsy, with two windows open onto
https://bugs.launchpad.net/ubuntu/+source/gfxboot/+filebug
into which I'd filled the respective bug details. When I was satisfied with my two reports I used the mouse to click "Submit Bug Report" on both pages, one quickly after the other.
Both bugs appears to have been filed correctly at:
https://bugs.launchpad.net/ubuntu/+source/gfxboot/+bug/131161
https://bugs.launchpad.net/ubuntu/+source/gfxboot/+bug/131160
But, the window for 131160 starts with two copies of the "Thank you for your bug report" (i)nformation item, and the window for 131161 has neither. Incidentally, I think I pressed submit first on the window that became 131161.
I will attach a screenshot. |
Symptoms
========
I just submitted two bug reports against the same package in Ubuntu nearly simultaneously. I did this using firefox from a slightly out-of-date gutsy, with two windows open onto
https://bugs.launchpad.net/ubuntu/+source/gfxboot/+filebug
into which I'd filled the respective bug details. When I was satisfied with my two reports I used the mouse to click "Submit Bug Report" on both pages, one quickly after the other.
Both bugs appears to have been filed correctly at:
https://bugs.launchpad.net/ubuntu/+source/gfxboot/+bug/131161
https://bugs.launchpad.net/ubuntu/+source/gfxboot/+bug/131160
But, the window for 131160 starts with two copies of the "Thank you for your bug report" (i)nformation item, and the window for 131161 has neither. Incidentally, I think I pressed submit first on the window that became 131161.
Cause
=====
The notification subsystem in Launchpad uses a session key that is in a cookie shared amongst all browser windows. POSTs are followed up by a redirect and the notification added to the GET of the page the browser was redirected to. The server then generates the page and dumps all outstanding notifications into the page content.
Possible fixes
==============
Include a notification reference in the redirect from the POST allowing a unique key to pickup specific notifications. (Users would see a query parameter on the url right after taking mutating-pageload-actions). That parameter would be ignored if they copy-pasted it.
Render the final result immediately rather than redirecting from the POST. Users taking mutating pageload actions would see the url that the action was POSTed too which (in our current system) might be a bit ugly. On the upside this would be significantly faster - less duplicate DB access, less roundtrips.
On the server side include the page the notification is for. Then when we dump notifications we'd only show the notifications that are relevant to the page the user ends up on. This is the simplest approach known of to-date. |
|
| 2011-05-10 08:28:22 |
Robert Collins |
tags |
lp-foundations |
lp-foundations ui |
|
| 2011-05-10 08:36:21 |
Robert Collins |
description |
Symptoms
========
I just submitted two bug reports against the same package in Ubuntu nearly simultaneously. I did this using firefox from a slightly out-of-date gutsy, with two windows open onto
https://bugs.launchpad.net/ubuntu/+source/gfxboot/+filebug
into which I'd filled the respective bug details. When I was satisfied with my two reports I used the mouse to click "Submit Bug Report" on both pages, one quickly after the other.
Both bugs appears to have been filed correctly at:
https://bugs.launchpad.net/ubuntu/+source/gfxboot/+bug/131161
https://bugs.launchpad.net/ubuntu/+source/gfxboot/+bug/131160
But, the window for 131160 starts with two copies of the "Thank you for your bug report" (i)nformation item, and the window for 131161 has neither. Incidentally, I think I pressed submit first on the window that became 131161.
Cause
=====
The notification subsystem in Launchpad uses a session key that is in a cookie shared amongst all browser windows. POSTs are followed up by a redirect and the notification added to the GET of the page the browser was redirected to. The server then generates the page and dumps all outstanding notifications into the page content.
Possible fixes
==============
Include a notification reference in the redirect from the POST allowing a unique key to pickup specific notifications. (Users would see a query parameter on the url right after taking mutating-pageload-actions). That parameter would be ignored if they copy-pasted it.
Render the final result immediately rather than redirecting from the POST. Users taking mutating pageload actions would see the url that the action was POSTed too which (in our current system) might be a bit ugly. On the upside this would be significantly faster - less duplicate DB access, less roundtrips.
On the server side include the page the notification is for. Then when we dump notifications we'd only show the notifications that are relevant to the page the user ends up on. This is the simplest approach known of to-date. |
Symptoms
========
I just submitted two bug reports against the same package in Ubuntu nearly simultaneously. I did this using firefox from a slightly out-of-date gutsy, with two windows open onto
https://bugs.launchpad.net/ubuntu/+source/gfxboot/+filebug
into which I'd filled the respective bug details. When I was satisfied with my two reports I used the mouse to click "Submit Bug Report" on both pages, one quickly after the other.
Both bugs appears to have been filed correctly at:
https://bugs.launchpad.net/ubuntu/+source/gfxboot/+bug/131161
https://bugs.launchpad.net/ubuntu/+source/gfxboot/+bug/131160
But, the window for 131160 starts with two copies of the "Thank you for your bug report" (i)nformation item, and the window for 131161 has neither. Incidentally, I think I pressed submit first on the window that became 131161.
Cause
=====
The notification subsystem in Launchpad uses a session key that is in a cookie shared amongst all browser windows. POSTs are followed up by a redirect and the notification added to the GET of the page the browser was redirected to. The server then generates the page and dumps all outstanding notifications into the page content.
Possible fixes
==============
Include a notification reference in the redirect from the POST allowing a unique key to pickup specific notifications. (Users would see a query parameter on the url right after taking mutating-pageload-actions). That parameter would be ignored if they copy-pasted it.
Render the final result immediately rather than redirecting from the POST. Users taking mutating pageload actions would see the url that the action was POSTed too which (in our current system) might be a bit ugly. On the upside this would be significantly faster - less duplicate DB access, less roundtrips.
On the server side include the page the notification is for. Then when we dump notifications we'd only show the notifications that are relevant to the page the user ends up on. This is the simplest approach known of to-date.
Use form nonces where the POST takes a nonce, visible in the referrer of the follow-on GET and thus usable to key into the notifications set. |
|
| 2011-12-31 20:25:37 |
Robert Collins |
tags |
lp-foundations ui |
lp-foundations notifications ui |
|
| 2011-12-31 20:31:16 |
Robert Collins |
description |
Symptoms
========
I just submitted two bug reports against the same package in Ubuntu nearly simultaneously. I did this using firefox from a slightly out-of-date gutsy, with two windows open onto
https://bugs.launchpad.net/ubuntu/+source/gfxboot/+filebug
into which I'd filled the respective bug details. When I was satisfied with my two reports I used the mouse to click "Submit Bug Report" on both pages, one quickly after the other.
Both bugs appears to have been filed correctly at:
https://bugs.launchpad.net/ubuntu/+source/gfxboot/+bug/131161
https://bugs.launchpad.net/ubuntu/+source/gfxboot/+bug/131160
But, the window for 131160 starts with two copies of the "Thank you for your bug report" (i)nformation item, and the window for 131161 has neither. Incidentally, I think I pressed submit first on the window that became 131161.
Cause
=====
The notification subsystem in Launchpad uses a session key that is in a cookie shared amongst all browser windows. POSTs are followed up by a redirect and the notification added to the GET of the page the browser was redirected to. The server then generates the page and dumps all outstanding notifications into the page content.
Possible fixes
==============
Include a notification reference in the redirect from the POST allowing a unique key to pickup specific notifications. (Users would see a query parameter on the url right after taking mutating-pageload-actions). That parameter would be ignored if they copy-pasted it.
Render the final result immediately rather than redirecting from the POST. Users taking mutating pageload actions would see the url that the action was POSTed too which (in our current system) might be a bit ugly. On the upside this would be significantly faster - less duplicate DB access, less roundtrips.
On the server side include the page the notification is for. Then when we dump notifications we'd only show the notifications that are relevant to the page the user ends up on. This is the simplest approach known of to-date.
Use form nonces where the POST takes a nonce, visible in the referrer of the follow-on GET and thus usable to key into the notifications set. |
Symptoms
========
I just submitted two bug reports against the same package in Ubuntu nearly simultaneously. I did this using firefox from a slightly out-of-date gutsy, with two windows open onto
https://bugs.launchpad.net/ubuntu/+source/gfxboot/+filebug
into which I'd filled the respective bug details. When I was satisfied with my two reports I used the mouse to click "Submit Bug Report" on both pages, one quickly after the other.
Both bugs appears to have been filed correctly at:
https://bugs.launchpad.net/ubuntu/+source/gfxboot/+bug/131161
https://bugs.launchpad.net/ubuntu/+source/gfxboot/+bug/131160
But, the window for 131160 starts with two copies of the "Thank you for your bug report" (i)nformation item, and the window for 131161 has neither. Incidentally, I think I pressed submit first on the window that became 131161.
Cause
=====
The page notification subsystem in Launchpad uses a session key that is in a cookie shared amongst all browser windows. POSTs are followed up by a redirect and the notification added to the GET of the page the browser was redirected to. The server then generates the page and dumps all outstanding notifications into the page content.
What we want to achieve is to notify a subset of events to the *current* window / process that is taking the action. This is perhaps something that the notification service should assist with - when the notification is a global one (vs e.g. 'field XYZ is not an integer'). This might be done by having the notification service API return a hint for 'include in the current action results'. Separately, *if* LP had a consistent timeline widget we could look at always including all subscribed events in responses to actions, and they would render on the right hand side; possibly client side logic could take care of all the side effects from the requested action.
Possible fixes
==============
* Include a notification reference in the redirect from the POST allowing a unique key to pickup specific notifications. (Users would see a query parameter on the url right after taking mutating-pageload-actions). That parameter would be ignored if they copy-pasted it.
* Render the final result immediately rather than redirecting from the POST. Users taking mutating pageload actions would see the url that the action was POSTed too which (in our current system) might be a bit ugly. On the upside this would be significantly faster - less duplicate DB access, less roundtrips.
* On the server side include the page the notification is for. Then when we dump notifications we'd only show the notifications that are relevant to the page the user ends up on. This is the simplest approach known of to-date.
* Use form nonces where the POST takes a nonce, visible in the referrer of the follow-on GET and thus usable to key into the notifications set.
* Move all 'this worked' etc notifications into the client side using the data returned from the API call. This would essentially deprecate the existing system. |
|
