(In reply to stephen.cunliffe from comment #16) > This is "cutting off your nose to spite your face" situation. I agree the cost/benefit here is somewhat debatable. > I don't agree with this solution (or to be honest, the *actual* problem) at all. So, the original problem looked pretty-bad -- it looks like the original attack here was in bug 868327 and there's a YouTube video showing the attack (spoofing google.fr in the URL bar): https://www.youtube.com/watch?v=tF5LTfQhSzw#t=0m42s I think that required the ability to show images in select menus which isn't possible at this point, so making a convincing attack is maybe a bit less tractable at this point. (In that bug, it looks like the solution may have allowed it to open downwards even though it doesn't fit, as you suggest) > I will however concede, that if the feeling is that any dropdown overlay, that actually extends up, over the URL bar is something we want to address, then fine, **IF** the dropdown is actually extending upwards instead of the 99.99% of the time that it extends downward, then go ahead and clip it to the viewport. > > However if the drop down, is extending down... like it does 99.99% of the time, then there is NO REASON to restrict the rendering of it to the viewport. That's a fair request. It looks like bug 1276976 comment 2 is where we came up with the current simple approach. I think there are still valid security concerns with allowing content to draw outside of the content area window *in general* (e.g. there might be some way to leverage that to trick a user into doing something bad), but it's probably a bit of a stretch for `select`-with-its-limitations to be the best way to do that Let's reopen and narrow this in on the feature-request of letting select menus overflow off the bottom of the content area. (One consideration here is what happens for iframes; I think right now, select menus are constrained to the iframe's bounds, but presumably a robust fix here would relax that restriction too, allowing an iframe to draw beyond its bounds [via a select menu-popup] in this one particular case).
Bug 1936615 Comment 17 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to stephen.cunliffe from comment #16) > This is "cutting off your nose to spite your face" situation. I agree the cost/benefit here is somewhat debatable. > I don't agree with this solution (or to be honest, the *actual* problem) at all. So, the original problem looked pretty-bad -- it looks like the original attack here was in bug 868327 and there's a YouTube video showing the attack (spoofing google.fr in the URL bar): https://www.youtube.com/watch?v=tF5LTfQhSzw#t=0m42s I think that required the ability to show images in select menus which isn't possible at this point, so making a convincing attack is maybe a bit less tractable at this point. (In that bug, it looks like the patch that landed may have allowed it to open downwards even though it doesn't fit, as you suggest; and we later restricted that in bug 1276976, as part of reimplementing select menu-popups as part of the "e10s" process-separation effort.) > I will however concede, that if the feeling is that any dropdown overlay, that actually extends up, over the URL bar is something we want to address, then fine, **IF** the dropdown is actually extending upwards instead of the 99.99% of the time that it extends downward, then go ahead and clip it to the viewport. > > However if the drop down, is extending down... like it does 99.99% of the time, then there is NO REASON to restrict the rendering of it to the viewport. That's a fair request. It looks like bug 1276976 comment 2 is where we came up with the current simple approach. I think there are still valid security concerns with allowing content to draw outside of the content area window *in general* (e.g. there might be some way to leverage that to trick a user into doing something bad), but it's probably a bit of a stretch for `select`-with-its-limitations to be the best way to do that Let's reopen and narrow this in on the feature-request of letting select menus overflow off the bottom of the content area. (One consideration here is what happens for iframes; I think right now, select menus are constrained to the iframe's bounds, but presumably a robust fix here would relax that restriction too, allowing an iframe to draw beyond its bounds [via a select menu-popup] in this one particular case).
(In reply to stephen.cunliffe from comment #16) > This is "cutting off your nose to spite your face" situation. I agree the cost/benefit here is somewhat debatable. > I don't agree with this solution (or to be honest, the *actual* problem) at all. So, the original problem looked pretty-bad -- it looks like the original attack here was in bug 868327 and there's a YouTube video showing the attack (spoofing google.fr in the URL bar): https://www.youtube.com/watch?v=tF5LTfQhSzw#t=0m42s I think that required the ability to show images in select menus which isn't possible at this point, so making a convincing attack is maybe a bit less tractable at this point. (In that bug, it looks like the patch that landed may have allowed it to open downwards even though it doesn't fit, as you suggest; and we later restricted that in bug 1276976, as part of reimplementing select menu-popups during the "e10s" process-separation effort.) > I will however concede, that if the feeling is that any dropdown overlay, that actually extends up, over the URL bar is something we want to address, then fine, **IF** the dropdown is actually extending upwards instead of the 99.99% of the time that it extends downward, then go ahead and clip it to the viewport. > > However if the drop down, is extending down... like it does 99.99% of the time, then there is NO REASON to restrict the rendering of it to the viewport. That's a fair request. It looks like bug 1276976 comment 2 is where we came up with the current simple approach. I think there are still valid security concerns with allowing content to draw outside of the content area window *in general* (e.g. there might be some way to leverage that to trick a user into doing something bad), but it's probably a bit of a stretch for `select`-with-its-limitations to be the best way to do that Let's reopen and narrow this in on the feature-request of letting select menus overflow off the bottom of the content area. (One consideration here is what happens for iframes; I think right now, select menus are constrained to the iframe's bounds, but presumably a robust fix here would relax that restriction too, allowing an iframe to draw beyond its bounds [via a select menu-popup] in this one particular case).
(In reply to stephen.cunliffe from comment #16) > This is "cutting off your nose to spite your face" situation. I agree the cost/benefit here is somewhat debatable. > I don't agree with this solution (or to be honest, the *actual* problem) at all. So, the original problem looked pretty-bad -- it looks like the original attack here was in bug 868327 and there's a YouTube video showing the attack (spoofing google.fr in the URL bar): https://www.youtube.com/watch?v=tF5LTfQhSzw#t=0m42s I think that required the ability to show images in select menus which isn't possible at this point, so making a convincing attack is maybe a bit less tractable at this point. (In that bug, it looks like the patch that landed may have allowed it to open downwards even though it doesn't fit, as you suggest; and we later restricted that in bug 1276976, as part of reimplementing select menu-popups during the "e10s" process-separation effort.) > I will however concede, that if the feeling is that any dropdown overlay, that actually extends up, over the URL bar is something we want to address, then fine, **IF** the dropdown is actually extending upwards instead of the 99.99% of the time that it extends downward, then go ahead and clip it to the viewport. > > However if the drop down, is extending down... like it does 99.99% of the time, then there is NO REASON to restrict the rendering of it to the viewport. That's a fair request. It looks like bug 1276976 comment 2 is where we came up with the current simple approach. I think there are still valid security concerns with allowing content to draw outside of the content area *in general* (e.g. there might be some way to leverage that to trick a user into doing something bad), but it's probably a bit of a stretch for `select`-with-its-limitations to be a workable way for an attacker to do that. Let's reopen and narrow this in on the feature-request of letting select menus overflow off the bottom of the content area. (One consideration here is what happens for iframes; I think right now, select menus are constrained to the iframe's bounds, but presumably a robust fix here would relax that restriction too, allowing an iframe to draw beyond its bounds [via a select menu-popup] in this one particular case).
(In reply to stephen.cunliffe from comment #16) > This is "cutting off your nose to spite your face" situation. I agree the cost/benefit here is somewhat debatable. > I don't agree with this solution (or to be honest, the *actual* problem) at all. So, the original problem looked pretty-bad -- it looks like the original attack here was in bug 868327 and there's a YouTube video showing the attack (spoofing google.fr in the URL bar): https://www.youtube.com/watch?v=tF5LTfQhSzw#t=0m42s I think that required the ability to show images in select menus which isn't possible at this point, so making a convincing attack is maybe a bit less tractable at this point. (In that bug, it looks like the patch that landed may have allowed it to open downwards even though it doesn't fit, as you suggest; and we later restricted that in bug 1276976, as part of reimplementing select menu-popups during the "e10s" process-separation effort.) > I will however concede, that if the feeling is that any dropdown overlay, that actually extends up, over the URL bar is something we want to address, then fine, **IF** the dropdown is actually extending upwards instead of the 99.99% of the time that it extends downward, then go ahead and clip it to the viewport. > > However if the drop down, is extending down... like it does 99.99% of the time, then there is NO REASON to restrict the rendering of it to the viewport. That's a fair request. It looks like bug 1276976 comment 2 is where we came up with the current simple approach. I think there are still valid security concerns with allowing content to draw outside of the content area *in general* (e.g. there might be some way to leverage that to trick a user into doing something bad), but it's probably a bit of a stretch for `select`-with-its-limitations to be a workable way for an attacker to do that. Let's reopen and narrow this in on the feature-request of letting select menus overflow off the bottom of the content area. (One consideration here is what happens for iframes; I think right now, select menus are constrained to the iframe's bounds, but presumably a robust fix here would relax that restriction too, allowing an iframe to indirectly draw beyond its bounds [via a select menu-popup] in this one particular case).