Closed Bug 266547 Opened 20 years ago Closed 5 years ago

change default for dom.disable_window_open_feature.status to false (allow sites to disable the status bar in popup windows)

Categories

(Firefox :: General, defect)

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: pursini, Unassigned)

References

()

Details

Attachments

(5 files)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10.1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10.1 The status bar on a popup window (activated by a link) still shows when the javascript function says to hide it: <a href="" onclick="javascript:window.open('http://www.moderngeek.com/cht/cht.php', 'applet','toolbar=no,location=no,directories=no,status=no,menubar=no,scrollbars=no,resizable=no,copyhistory=no,width=650,height=430'); return 0;">Pop chat up in new window</a><br> the status=no is suposed to hide the status bar when the window pops up, however firefox seems to be disregarding it. Internet Explorer Sp2 shows it too, but not in anything pre-sp2. Reproducible: Always Steps to Reproduce: 1. Go to the URL mentioned 2. open the window 3. notice there is still a status bar in the new window, however there isn't susposed to be one Actual Results: the status bar shows up in the new window Expected Results: there shoudn't be a status bar in the new window.
That is by design: individual users can choose to let pages hide their statusbar, but by default the preference dom.disable_window_open_feature.status is set true. See bug 259192 and friends.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → INVALID
I'm requesting that this is set to false so that by default, so that a website opening a popup can hide the status bar. This can be useful for preference pages, or HTML chats that refresh the page every X seconds, as the status bar can become tedious. I see no harm in allowing the statusbar to be hidden in a website creating a window, unless it is an unrequested popup. As as user of firefox, and web developer, I am humbly requesting that these changes be made. (In reply to comment #1) > That is by design: individual users can choose to let pages hide their > statusbar, but by default the preference dom.disable_window_open_feature.status > is set true. See bug 259192 and friends.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
i'll add my voice to the "please fix this" camp. Preference should be set to false by default.
I'm pretty sure this is a wontfix since the status bar was made visible on purpose (see bug 252811). The latest IE does the same, btw
So, mozilla is now copying it's security techniques off of IE? Has the world gone mad? The older IE did it the other way, but I think we need to rethink our principles before marking this as a nofix.
I agree. My concern is that this "intentional bug" will end up aesthetically breaking a large percentage of sites out there, mine included. I always design sites that use pop-up windows to open them without status bars, and i often design those pop-up windows with very little tolerance for the extra chrome that isn't supposed to show up because i told it not too. Especially when you consider the dubious benefit of forcing the status bar to always be visible (which is something the general user this is supposed to help will NOT notice). Leave it as an option for the power users and the paranoid security fanatics, but don't break half the web for the designers who build it and the users who won't appreciate the "feature" anyway.
I'll add my voice to this. My own pop-up windows to show enlargements of photographs now not only looks aesthetically worse with the status bar showing, but also it results in an incorrect size calculation and a lot of pixels at the bottom are now covered up. I, for one, feel very disheartened at needless tweaking for reasons which are seamingly on the paranoic, and which forces me to change code in sites which I've been designing for the last ten years. Having standards in computing is a winderful thing - the really great thing about them is that there are so many to chose from. Re-enable the status bar removal please. I'd rather not have to go through the massive amount of recoding for all my sites because someone had what they thought was a bright idea.
Sorry ... needed to add something further here - the browser seems to be identifying itself as Netscape by default and unless someone changes the preferences (an option to change it's identification by the GUI doesn't seem to exist) then it is seemingly impossible for me to detect the browser and make any mathemtcial adjustment in my code for the fact that the status bar will cause a calculation error; so I can't adjust for the fact that the status bar hasn't been removed. What seems like such a small thing is causing so much annoyance. Much work goes in to aesthetics and to have it deliberately broken is not good for my blood pressure. The very people who make the kind of error that the status bar change is supposed to protect, don't even know what the "lock" is for, let alone to look down there for the confirmation of the site domain.
Is there an official word on whether this will be fixed? I'm still not clear on how the mozilla developers can disable a feature that is well documented where ever you look: status=off Why would there be this option if what wasn't meant to be used by website developers?
I, also, would like official word of what is to become of this bug in the next release. It is too widely used by the web community to remain unfixed. There is still no word of a work-around for the increasing number of version 1 browsers that seem to be out there, and I am starting to get tired of telling people who complain to me about my sites, that they have to re-set an option in their browser preferences; the majority of them aren't really clued up enough about computers to edit these files, and a few of these "support" instances have really chewed up large chunks of my time and engendered bad feelings. If it gets to the stage when I've got to put up a general instruction on my sites for Firefox users, it will be a sad day from my point of view.
It should be mentioned that hiding the status bar allows malicious websites to display a phony status bar, complete with a phony SSL padlock that links to a phony certificate display. This enables effective phishing techniques. It seems to me that when Firefox ignores a request to hide the statusbar, it should automatically add the height of the statusbar to the requested height of the window. This avoids the statusbar covering up content, or requiring site authors to add (often unsightly) "just in case" height to the popup.
i think it is well understood that this has been done for "security" reasons. however, the fact remains that this action is counter to established and accepted web browser behavior, and will have an aesthetically detrimental effect on millions of innocent websites. the alternative solution--accounting for the forced statusbar in window size calculations when the window is requested to open without it--would be about the only viable solution aside from fixing this intentionally broken behavior. in fact, if we're worried about phishing, i'd rather see a forced security alert if the statusbar is hidden, a form submission has been initiated, and the page is insecure (even if the user has requested no security notifications on form submit). i think this would be the most reliable way to warn the less net educated users to a potential security situation--put it in their face.
WONTFIX per 299424 comment 7, bug 259192, and bug 252811.
Assignee: bugs → nobody
Component: JavaScript Console → General
OS: Windows XP → All
QA Contact: javascript.console → general
Hardware: PC → All
Summary: Status bar still shows when javascript popup field says not to. → change default for dom.disable_window_open_feature.status to false (allow sites to disable the status bar in popup windows)
Status: NEW → RESOLVED
Closed: 20 years ago19 years ago
Resolution: --- → WONTFIX
(In reply to comment #12) > however, the fact remains that this action is counter to established and > accepted web browser behavior, and will have an aesthetically detrimental > effect on millions of innocent websites. Phishers are taking advantage of "accepted web browser behavior", the browser has to adapt. IE has also adopted the "forced statusbar" approach; Opera has adopted the "forced locationbar-lite" approach which would be my preference (see bug 22183. Set pref dom.disable_window_open_feature.location to true to see how it looks in Firefox). We got far more objections from website designers to the forced locationbar-lite approach than to the forced statusbar. Either way we can't go back to the pre-phishing web behavior.
Phishing is a social problem, not a technical one. The better approach would be for FireFox to behave the same way google does with it's email service. "The website you are going to appears to be doing something suspicious...." Then you can allow the user to trust "Blah Blah.com" not not to trust 125.4.1.17. The thing is to avoid this becoming the same thing that the Active X accept button did for auto installs. I'm sure there is a better way of addressing this than just disabling/breaking features for everyone. (In reply to comment #14) > (In reply to comment #12) > > however, the fact remains that this action is counter to established and > > accepted web browser behavior, and will have an aesthetically detrimental > > effect on millions of innocent websites. > > Phishers are taking advantage of "accepted web browser behavior", the browser > has to adapt. IE has also adopted the "forced statusbar" approach; Opera has > adopted the "forced locationbar-lite" approach which would be my preference > (see bug 22183. Set pref dom.disable_window_open_feature.location to true to > see how it looks in Firefox). We got far more objections from website designers > to the forced locationbar-lite approach than to the forced statusbar. Either > way we can't go back to the pre-phishing web behavior. >
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
> I'm sure there is a better way of addressing this than just disabling/breaking > features for everyone. Feel free to suggest such a way; we haven't been able to think of one, and not for lack of trying.
You must have not read the whole comment. We should have an information bar that drops down and addresses the problem to the user. Make it designed to where the user will have to actually read it (wait a few secs before OK button shows up). Have it inform the user about Phishing and the dangers of it. Just like gmail does when you get a suspected Phishing email, or IE when you get a popup. Education is the best way of preventing phishing, not lockouts. (In reply to comment #16) > > I'm sure there is a better way of addressing this than just disabling/breaking > > features for everyone. > > Feel free to suggest such a way; we haven't been able to think of one, and not > for lack of trying. >
> Education is the best way of preventing phishing, not lockouts. Heartily agreed. Arbitrarily changing systems that break other peoples code that has worked for decades is no way to go forward. Nor, Mozilla Staff, is it any use in ignoring an issue like this in the hope that peope will forget it, or that time makes it the default.
IE 6.0.2800.1106, the latest I can install on Windows 2000 workstation, (acording to Microsofts own Windows Update) shows no such bar and my pictures display as intended. I shall try and get a variation of 6.5 to work and test it. Opera is worse than Mozilla, it shows a slip with the domain name at the top; that looks completely unprofessional, is ugly-looking, and totally out of place with the image pop-ups. I'm making a separate complaint to them. Mozilla at least looks more professional; but I argue that you can go back to the way things were. Like has been said previously in this argument, the very people you are trying to protect, wouldn't know what they are looking at anyway. The majority of the important pishing attempts I have seen involve a link that is completely false from being included in an e-mail. One alternative is a bar in the source window, allowing the user to select a parameter whether they trust the site or not, and maintain a list locally of the sites that the user trusts, like the IE warning bar. I still fail to see why the functionality of all the sites I have designed and built over the years that uses this code, should suffer because of lack of thought or ingenuity on the behalf of Mozilla's coders.
Attached file Test Case
Here is a test case.
Attached image Firefox 1.0.7 Popup
Attached image IE 6 on Win2003 sp2
Attached image Opera 8.5 Popup
There appears to be some confusion regarding this bug. First, the history: In the naive early days of the web, browsers allowed JavaScript to hide the statusbars of popup windows. Some people[1] eventually noticed that a phony statusbar or addressbar could be put in its place, including a phony SSL lock icon that linked to a phony SSL certificate popup window. The phony statusbar/addressbar can be generated using XUL[2-4], or (X)HTML+CSS. Without some reliable, persisent indicator, there is no way for the user to tell what parts of a browser window are real and what parts are generated by the website, making the whole program untrustworthy. This has nothing to do with emails. And, really, trading a minor cosmetic problem to be able to see where stuff is coming from is not a difficult choice. While phishing is largely a social problem, the only tool users have to avoid it is technology. Though the browser cannot prevent phishing, it can give users the tools they need to make it much harder. An information bar would require Firefox to render the page in memory, and check to see if a phony statusbar was part of every single popup that blocked the statusbar. It could not even just look for an exact match of the real statusbar, but anything effective enough to fool the user. Without getting into too much detail, it would require some very sophisticated heuristic OCR technology that would likely double the size of Firefox and slow it immeasureably. If an info bar appeared indiscriminantly for any statusbar-less popup, how would that be better than just keeping the statusbar? Would it somehow be more attractive? It could certainly be more alarming to an already twitchy public. Of course this is basically what Opera does now. Mozilla Firefox made the decision to make the statusbar persistent and reliable (I believe IE7 has made the same decision; Opera chose a variation on the addressbar). This has created some frustration since the height of the statusbar has not been added to the height of the requested statusbar-less popup. This is probably a bug, and should be reported in a separate ticket. However, no old code was "broken", unless the popup contains something crucial at its bottom that is tiny enough to be completely covered by the unexpected statusbar. Slightly unattractive popups are not the same as broken code, and they sure as hell cause no "suffering". Please refrain from deliberately inflammatory language (I have a medical condition that excuses mine. ;) ) Ignoring the potential for trouble, and naively turning back the clock is not going to work, either. People have been widely conditioned to trust the padlock. If even a single site spoofs that, there will a media outcry, and serious economic impact. This change happened long enough ago that new applications have had plenty of time to take it into account. The web as we know it is barely a decade old. There will be changes. IE, for example, frustrated a great many web app developers when IE6 appeared and stopped blindly accepting third-party cookies. If you are looking for static, unchanging development environment, check out OS/2 or DOS, because the web is just going to frustrate you. Making changes to the window that opens the popup (the parent) simply will not be seen by the vast majority of users. Would you look *behind* the current window? How would that even work? How would the parent window concisely convey the concept "The true website for the popup that currently has the focus (not this window) is ..."? If you still feel that there has been a lack of thought or ingenuity on behalf of Firefox developers, please let me offer you a full refund. [1] http://www.trickytools.com/security/check-your-computer/firefoxspoof_files/firefoxspoof.html [2] https://bugzilla.mozilla.org/show_bug.cgi?id=244965 [3] http://secunia.com/advisories/12188/ [4] http://www.extensionsmirror.nl/lofiversion/index.php/t586.html
> This has nothing to do with emails. It has everything to do with e-mails, E-mails start the browser without using a pop-up. The only way the user has a chance is to look at the code behind teh highlighted link to see where it is going. > And, really, trading a minor cosmetic problem to be able to see where stuff is coming from is not a difficult choice. Minor cosmetic problem? Tell that to my customers for whom all the code has to be re-written. I've been threatened with legal action over this. It has done nothing for my blood pressure. Not only that, but I've tried re-coding to take account of the height issue, but with every browser now doing something different, and also then going and identifying as something completely different, it is impossible to code things at the Java end - every browser needs to be singing from the same song sheet, or the whole Internet browsing experneice falls apart. > While phishing is largely a social problem, the only tool users have to avoid > it is technology. Though the browser cannot prevent phishing, it can give > users the tools they need to make it much harder. Agreed, but this is the wrong tool. > An information bar would require Firefox to render the page in memory, > it would require some very sophisticated heuristic OCR > technology that would likely double the size of Firefox and slow it > immeasureably. ? You're kidding me. The other leg has bells on. What is wrong with adding code to the cached page and then re-rendering? > Slightly unattractive popups are not the same as broken code, It's broken. It is not adhering to the standards. It is not listening to the call to remove the status bar ... ie. it's broken. The fact that Mozilla coders deliberately coded the bug is another matter. > People have been widely conditioned to trust the padlock. I don't trust the padlock. Never have and never will. I use my intuition as to whether or not I trust a site. > If even a single site spoofs that, there will a media outcry, and > serious economic impact. Your view on society is far different to mine :-) > This change happened long enough ago that new applications have had plenty of > time to take it into account. As I said, it is impossible to take it in to account. Everyone is doing something different. My versions of IE operate as expected. Firefox is putting the status bar at the bottom and failing to alow for the correct image height, and Opera are making their address part of the image. It really is not acceptable. > The web as we know it is barely a decade old. There will be changes. I have been around the Internet for more than that decade. From my point of view, there has been more stability lately than ever before in the underlying code, and I've never before seen something as ludicrous as this problem which has broken pop-up code that I wrote years ago. IE's changes have happened, agreed, and they have been real pains in the A, but they have at least always been backwards compatible. > Making changes to the window that opens the popup (the parent) simply will > not be seen by the vast majority of users. The status bar asks for permission before the pop-up is opened ... or you could even make it another pop up warning! Something that simply asks the user as to whether or not they trust this site to open pop-ups and then remembers the decision. The same way that cookies are dealt with now and that the system uses to remember the decision. The images you have posted do not show the problems I am having. When I wake properly, I'll post the troubles that are occuring. The net evolves, yes, but it historically doesn't break past code, like this deliberately coded bug has caused. There are still people out there using Windows 3.1 (I know, it's sad, but there you go) and the number of Windows 98 machines still running is amazing. They will never upgrade their browsers beyond security patches and, for them, all my pop-up sites are now broken. Tell your case to the lawyers who want to sue me for not doing my job as a designer, and the customers that want partial refunds. Mozilla's attempt to play nice and benefit society is causing serious grief to the society that I know; litigious and money grabbing. I haven't taken another web design contract since this problem reared its head. My career as a designer is up in smoke because of this and that is no joke. > If you still feel that there has been a lack of thought or ingenuity on behalf > of Firefox developers, please let me offer you a full refund. Cheap shot. "Free" does not vindicate Mozilla in any way for deviating from standards and imposing its own design implications on the rest of the world ... do I sense a minature rebirth of IE here?
To Answer Boris in comment 16, I believe two valid options have been presented. from comment 11 : "...when Firefox ignores a request to hide the statusbar, it should automatically add the height of the statusbar to the requested height of the window." from my own comment 12: "...a forced security alert if the statusbar is hidden, a form submission has been initiated, and the page is insecure" comment 15 also is simliar to this, as is 17. if the response we see from Brian in comment 24 is any indication of what the developers are thinking, it is obvious why this problem exists in the first place. "An information bar would require Firefox to render the page in memory, and check to see if a phony statusbar was part of every single popup that blocked the statusbar" This is utterly ridiculous, first off. There is no need to jump through all the hoops you are imagining to help insure the user's security, and no one has suggested attempting to make changes to the "parent" window of a suspicious popup. What we're attempting to protect against is effectively this: a user being presented with a form (to accept information) from a window with no standard chrome. Protecting the user while also allowing developers to use a well-documented standard feature of the window.open function is as simple as this: 1) window.open fires specifying explicitly or implicity that the statusbar should not show 2) page that loads has a form 3) ON FORM SUBMIT, pop-up an alert/request box informing the user of the insecure or suspicious nature of this form This will protect the user by forcing her to deal with the fact that the situation is questionable, while protecting the work legitimate developers have done to make visiting their site a pleasant experience. Oh, and if you disable a standard, well-understood, and widely used feature of one of the most used functions of your product, then yes, you have *broken* the code that uses it, whether it was used for a purely aesthetic purpose or not, and whether you negatively impact the functionality or usability of the effected code or not. A simple solution that doesn't involve breakage of existing code or freakishly over-involved code-sniffing has been presented for your consideration.
You know ... I've been putting these pictures together, (uploaded shortly, after I've had coffee) and all that is shown in the bottom status bar is, "Done..." (FF0.8 on W2K and 1.0.7 on Suse 9.3) Can someon kindly remind me how this is supposed to protect people against phishing again please?
First picture ... Firefox 1.0.7 on Linux - note the botton status bar doesn't actually say anything other than "Done..." http://www.msknight.com/ff107linux.jpg
Second picture ... Opera adds the title to the top of the image and knocks the feet off the bottom http://www.msknight.com/opera.jpg (Yes, the picture is me, so please don't laugh. Also, given the legal hoo hah I'm having, I'm not using the clients images, for whom these border matters are more important, especialy on smaller image blow-ups, including maps.) MORE IMPORTANTLY - Please note that with the previous 1.0.7 firefox image, it looks like Firefox has also resized the image and made it smaller. Now I am starting to get annoyed as this removes further ability to render an image faithfully. I'll check this further once I've got all the images together.
Now for IE 6 - image properly rendered and pop up the same size without the lower status bar ... http://www.msknight.com/ie6.jpg I need more coffee.
Regarding zooming, my apologies, it is not automatically zooming the image. Tis is what happens before I've have my morning coffee, I halucinate. However there seems to be another problem with image width difference also that I'll investigate later. I can not download Firefox 1.0.7 for Windows, it just don't wanna come. It does seem, however, that 1.0.7 at least adds the extra lines so that the image is at least rendered in full, whereas 0.8 (which is when this all started) chopped the bottom lines off, which was a line of text on some map images, and on some sales images of products; necesitating re-working the images or re-working the code. If all this is about a padlock, why not put it in the top status bar? Why force-enable the lower bar just to display the padlock? It is insanity! And as for Operas resolution to the situation ... that is just unforgivable. When I finally manage to get 1.0.7 for Windows downloaded, I'll post the results.
> It does seem, however, that 1.0.7 at least adds the extra lines so that the > image is at least rendered in full, I knew I spoke too soon. It doesn't render the image in full. See the paving slabs at the bottom right. What is wrong, with a web site designer asking the browser for a new window, X by Y, so that an image of X by Y can be displayed. Why do I have to try and code Javascript that tries to recognise browser A from browser B and Browser C, and all the different versions in between, so that it can request a few more pixels here, or a few less pixels there, to get a window the right size to display the image properly? And as I heve mentioned before, with browsers pretending to be other browsers, it is impossible for the poor web designer to achieve a simple thing like opening a pop-up window of X by Y. This is insanity, and I'm more than willing to fight the corner of the web developer in this case, as we have been walked all over by IE in the past, and now I see us being walked all over by Mozilla and Opera in the same fashion over issues like this bug. It is a sad state of affairs and shouldn't have happened in the first place. 1.0.7 still doesn't want to download. Hangs at 3.8 Meg downloaded. I'll try again later.
First, my attachments are meant only to illustrate what a popup in the major browsers looks like when the statusbar is not requested. They are not meant to show any security features. Yes, the statusbars all say "Done". With a little imagination, it should be obvious that an image can be added to the IE6 popup that looks like a secure site, with a padlock that links to a phony certificate popup that says "PayPal" or "citibank". Look, a popup without a status or address bar can have a fake lock that makes it appear to be secure, and appear to be a site that it is not. > >This has nothing to do with emails. > > It has everything to do with e-mails, E-mails start the browser without using a > pop-up. The only way the user has a chance is to look at the code behind teh > highlighted link to see where it is going. I don't know of any email programs that allow script to hide the statusbar, so I still fail to see how email has anything to do with this discussion. > Minor cosmetic problem? Tell that to my customers for whom all the code has to > be re-written. I've been threatened with legal action over this. It has done > nothing for my blood pressure. Not only that, but I've tried re-coding to take > account of the height issue, but with every browser now doing something > different, and also then going and identifying as something completely > different, it is impossible to code things at the Java end - every browser > needs to be singing from the same song sheet, or the whole Internet browsing > experneice falls apart. If you guaranteed an application to work for all future web browsers, something entirely outside your control, then you have to expect bumps like this. If you've taken litigous clients, you have to expect threats of lawsuits. Here's how to fix it: add 24 pixels to the to the requested window height in the function that sets the window properties. Some browsers will have a minor gap at the bottom. You did use a single function rather than doing it in dozens of places, right? Again, the web changes quickly and frequently--it's still in its infancy. > > While phishing is largely a social problem, the only tool users have to avoid > > it is technology. Though the browser cannot prevent phishing, it can give > > users the tools they need to make it much harder. > > Agreed, but this is the wrong tool. Touche. Seriously, why? Because this particular solution causes you headaches? Would a solution that bothers someone else be better? > > An information bar would require Firefox to render the page in memory, > > it would require some very sophisticated heuristic OCR > > technology that would likely double the size of Firefox and slow it > > immeasureably. > > ? You're kidding me. The other leg has bells on. What is wrong with adding > code to the cached page and then re-rendering? What does this even mean? Listen, if you think adding some pixels of popup height is hard, just try writing code to scan a page for a phony statusbar! > It's broken. It is not adhering to the standards. It is not listening to the > call to remove the status bar ... ie. it's broken. The fact that Mozilla > coders deliberately coded the bug is another matter. I'm afraid that's just wrong. There is no "standard" that defines window.open(). It is a convention browsers have typically honored, though they have all done it a little different. How many vendors implemented "fullscreen", "titlebar", "chrome", or "modal"? That means it is likely to change at the whim of each vendor. That's why standards pedants have been hounding Microsoft in recent years. > > People have been widely conditioned to trust the padlock. > > I don't trust the padlock. Never have and never will. I use my intuition as > to whether or not I trust a site. Well, I guess that effectively contradicts anything I've seen from Forrester. > > This change happened long enough ago that new applications have had plenty of > > time to take it into account. > > As I said, it is impossible to take it in to account. Everyone is doing > something different. Just add the 24 pixels (to all of the browsers). > My versions of IE operate as expected. Firefox is putting the status bar at > the bottom and failing to alow for the correct image height, and Opera are > making their address part of the image. It really is not acceptable. I agree that Firefox should add the statusbar height to the requested popup height when the statusbar is not requested. That would be a simple, elegant solution to this problem. > > The web as we know it is barely a decade old. There will be changes. > > I have been around the Internet for more than that decade. From my point of > view, there has been more stability lately than ever before in the underlying > code, and I've never before seen something as ludicrous as this problem which > has broken pop-up code that I wrote years ago. IE's changes have happened, > agreed, and they have been real pains in the A, but they have at least always > been backwards compatible. Any stability in the code stems from stagnation and complacency at Microsoft. Betting your career on it seems ill-advised. IE's changes have certainly NOT always been backwards compatible! Geez, that's why I brought up third-party cookies! > > Making changes to the window that opens the popup (the parent) simply will > > not be seen by the vast majority of users. > > The status bar asks for permission before the pop-up is opened ... or you could > even make it another pop up warning! Something that simply asks the user as to > whether or not they trust this site to open pop-ups and then remembers the > decision. The same way that cookies are dealt with now and that the system > uses to remember the decision. The status bar asks for permission? What do you mean? Another warning? Just because I trust a site, that doesn't mean I trust every site they link to (popup or no). Sites pop up other sites, and I want to know where the hell I am! > The images you have posted do not show the problems I am having. When I wake > properly, I'll post the troubles that are occuring. The net evolves, yes, but > it historically doesn't break past code, like this deliberately coded bug has > caused. There are still people out there using Windows 3.1 (I know, it's sad, > but there you go) and the number of Windows 98 machines still running is > amazing. They will never upgrade their browsers beyond security patches and, > for them, all my pop-up sites are now broken. Just add the pixels, already! > Tell your case to the lawyers who want to sue me for not doing my job as a > designer, and the customers that want partial refunds. Mozilla's attempt to > play nice and benefit society is causing serious grief to the society that I > know; litigious and money grabbing. I haven't taken another web design > contract since this problem reared its head. My career as a designer is up in > smoke because of this and that is no joke. Again, you have to take some responsibility if you overpromised or contracted with any evil client. You cannot guarantee browser code that you don't control. Besides, if you find adding the pixels so hard, I'd probably be a pretty irritated client, too. > > If you still feel that there has been a lack of thought or ingenuity on behalf > > of Firefox developers, please let me offer you a full refund. > > Cheap shot. "Free" does not vindicate Mozilla in any way for deviating from > standards and imposing its own design implications on the rest of the world ... > do I sense a minature rebirth of IE here? It's not a standard. It's a convention. > if the response we see from Brian in comment 24 is any indication of what the > developers are thinking, it is obvious why this problem exists in the first > place. > "An information bar would require Firefox to render the page in memory, and > check to see if a phony statusbar was part of every single popup that blocked > the statusbar" > > This is utterly ridiculous, first off. There is no need to jump through all the > hoops you are imagining to help insure the user's security, and no one has > suggested attempting to make changes to the "parent" window of a suspicious > popup. No, it isn't necessary. The statusbar could simply display, making phony padlocks obvious. Admittedly, if it ignores the request to hide the statusbar, it should automatically add the statusbar's height to the popup. > What we're attempting to protect against is effectively this: a user being > presented with a form (to accept information) from a window with no standard > chrome. > > Protecting the user while also allowing developers to use a well-documented > standard feature of the window.open function is as simple as this: > 1) window.open fires specifying explicitly or implicity that the statusbar > should not show > 2) page that loads has a form > 3) ON FORM SUBMIT, pop-up an alert/request box informing the user of the > insecure or suspicious nature of this form And what if it isn't a form, but a link to a form, or a redirect to a form, or a link to a redirect to a form? Does a separate process have to watch the popup forever to check for possible suspicious activity? > This will protect the user by forcing her to deal with the fact that the > situation is questionable, while protecting the work legitimate developers have > done to make visiting their site a pleasant experience. As big as this issue is to you, to most people, even most developers, it isn't that important. We just adapt. > Oh, and if you disable a standard, well-understood, and widely used feature of > one of the most used functions of your product, then yes, you have *broken* the > code that uses it, whether it was used for a purely aesthetic purpose or not, > and whether you negatively impact the functionality or usability of the > effected code or not. If that standard is inherently insecure, and you are made or broken by your security reputation, you'll probably reconsider the feature, rather than pretending the problem will go away. > A simple solution that doesn't involve breakage of existing code or freakishly > over-involved code-sniffing has been presented for your consideration. Sadly, it's a little naive; it just doesn't take the complexity of the situation into account. Look, I'll double-check IE7, but if Microsoft and Opera have done basically the same thing, won't that basically prove the point that many, many smart people have come to the same conclusion? And yes, Firefox, like IE, scales images to the viewable area by default.
We need to get the purpose of this bug straight ... If a designer requests that a browser opens a pop window of a desired height and width, then the browser should do so. I shouldn't have to add pixels here and there. However, that is what designers like me have to do in order to get around the whims of the browser creators. When browsers hide their identity or behave like other browsers to get around each others quirks, designers like me don't stand a chance of knowing which browser is being used in order to make the right corrections. When I want Firefox to open a window X by Y I want it to do it. I don't want it to impose its own status bar on top of the window I've requested to be opened ... no matter what the reason ... user security, phishing, whatever. What I care about is that when my code tells Firefox to open a window of X by Y, that this is what it does. I have a right to expect browsers to adhere to some form of standard. It is impossible for me to program for browsers that hide in a world of their own and think that they are the be all and end all. They have a job, and that is to render code correctly. Pishing E-mails include links that open browser sessions that start from first opening ... they are very much to do with it ... they bypass the whole pop-up issue by starting a browser session that points straight to a phishing server.
(In reply to comment #34) > We need to get the purpose of this bug straight ... > > If a designer requests that a browser opens a pop window of a desired height > and width, then the browser should do so. I shouldn't have to add pixels here > and there. I completely agree. However, this bug is titled "change default for dom.disable_window_open_feature.status to false (allow sites to disable the status bar in popup windows)", which isn't really the same. I think that if we want action by the developers, a new bug called "add height of unrequested statusbar to popup height" should be opened. > However, that is what designers like me have to do in order to get around the > whims of the browser creators. > > When browsers hide their identity or behave like other browsers to get around > each others quirks, designers like me don't stand a chance of knowing which > browser is being used in order to make the right corrections. Actually, I've compiled some methods that use browser features rather than the notoriously unreliable user agent string. Check out http://webcoder.info/reference/BrowserFiltering.html > When I want Firefox to open a window X by Y I want it to do it. I don't want > it to impose its own status bar on top of the window I've requested to be > opened ... no matter what the reason ... user security, phishing, whatever. I agree that the requested area should take into account any changes to the request. But I also think the browser has the right to display things however it needs to in order to stay alive. How does Safari (the #3 browser) do it? I'll check when I get a chance. K-Meleon opens all requested popups in a new tab. PocketIE and WebTV don't really support multiple windows. And it's looking like chromeless popups will soon be unavailable. We must adapt, just as when Windows XP appeared, and the fatter titlebar forced us to resize many popups. > What I care about is that when my code tells Firefox to open a window of X by > Y, that this is what it does. I have a right to expect browsers to adhere to > some form of standard. It is impossible for me to program for browsers that > hide in a world of their own and think that they are the be all and end all. > They have a job, and that is to render code correctly. You'll get no argument from me on this point. Standards adherence is critical, when there is a standard to follow. In this case, there is no set standard. CSS3 will control popup behavior, but that is years away. The XML DOM may standardize popup properties for XHTML (when served with the correct application/xhtml+xml MIME type), I'm not sure off the top of my head. > Pishing E-mails include links that open browser sessions that start from first > opening ... they are very much to do with it ... they bypass the whole pop-up > issue by starting a browser session that points straight to a phishing server. Exactly: they bypass this issue.
> I completely agree. However, this bug is titled "change default for > dom.disable_window_open_feature.status to false (allow sites to disable the > status bar in popup windows)", which isn't really the same. It all came about when Mozilla stopped allowing sites to disable the status bar in pop up windows. That is the action that the developers took which triggered the whole thing, and is why the bug is entitled so. The precise wording is another issue that isn't really (in my humble oppinion) worth that much arguing over. The fact is simple; they took action which introduced what I personally, (and also others, such as the creator of the bug report) see as a bug and broke an awful lot of code that has been out there for years. Not only that, but they refused to undo the changes to bring the behaviour back in to line with other browsers. Look at the effect that Opera's knee jerk reaction is; their pop-ups now look hidious; all because they didn't take a litle time to think their actions out properly. Not only that, but it is possible to create a link that bypasses their code, simply by putting an anchor in at the top of the image and calling the anchor in the link. They didn't think; just like Mozilla didn't think it through properly when they made their code change and the consequences speak for themselves, as well as the fact that this bug report has been open for more than a year. Thanks for the links to the suggestions. I'll follow them up when I get a chance, but like I said, it is too late for me. I'm now in a world where it's who has the best legal ace that wins the hand and the time just drags. For now, I'm unwinding with a movie and some wine before work tomorrow. Looks like you've got an interesting site there.
(In reply to comment #36) > The precise wording is > another issue that isn't really (in my humble oppinion) worth that much arguing > over. While this should be true, I've found that the wording for some of the bugs I've submitted or voted for in the past have had to be marked "invalid" or "wontfix" and replaced by subtly differing versions before anything really happened. Programmers can be a pedantic lot. :)
We do need to get the purpose of this bug straight. The main focus of this bug should be reversing the bad decision to disallow developers from specifying a pop-up window without a status-bar. If we want to pursue the other presented options (the window height issues), we should do so in a separate bug. Bottom line is that disallowing statusbar removal is of questionable security value at best, and the security purposes we're pursuing would be better served by MORE SPECIFIC methods (also to be addressed in a separate bug if discussion here proves fruitful). So, i would say that we need the developers to weigh in on the validity of the proposed security changes, and whether the standard feature we have come to rely on can be re-instated.
I have filed bug 317297 to request the security measures i proposed to replace the forced statusbar. I have considered marking this bug as depending on bug 317297, as we are dealing with a valid security concern for which this (forced statusbar) is *a* solution (however incorrect), but I will leave that for those more savvy in the ways of bugzilla and Mozilla development.
What about making the status bar removable, but putting in the added height of the page where a would-be status bar would normally be? You don't want the status bar? OK, but you have to have 10 extra pixels at the end of your page so a fake status-bar would rise 10 pixels up, and be unbelievable. This might be a happy medium so that it would be a little more ascetically pleasing, and a little more security-centric. (In reply to comment #39) > I have filed bug 317297 to request the security measures i proposed to replace > the forced statusbar. > > I have considered marking this bug as depending on bug 317297, as we are > dealing with a valid security concern for which this (forced statusbar) is *a* > solution (however incorrect), but I will leave that for those more savvy in the > ways of bugzilla and Mozilla development. >
I would also consider this aesthetically unnacceptable. It also doesn't really address the reason the status-bar is being forced in the first place--the idea that the un-spoofable status bar shows a lock icon if the page is secure, thus *informing the user of security status*. Your suggestion also wouldn't work because page content can extend below the bottom border of a window without triggering scrollbars. thus the statusbar could still be placed at the bottom, with the 10-pixel forced margin below the bottom of the window and out of view. To make this suggestion workable, you'd have to *also* disable a developer's ability to control overflow in windows, iframes, and other block-level elements. (In reply to comment #40) > What about making the status bar removable, but putting in the added height > of the page where a would-be status bar would normally be? You don't want the > status bar? OK, but you have to have 10 extra pixels at the end of your page > so a fake status-bar would rise 10 pixels up, and be unbelievable. This might > be a happy medium so that it would be a little more ascetically pleasing, and > a little more security-centric.
Being able to see the host for the SSL certificate is not of "questionable value" to me. Also, knowing that the statusbar I see is real, without any doubt, is not of "questionable value" to me. Frankly, I think the addressbar should also be persistent (or a simplified version, as Opera does). I want to see where I am. And form submission is not the only risk in a popup. I cannot immediately see where links go, for example.
Attached image IE7 on WinXP
Confirmed: the first IE7 beta also forces the status bar.
Safari 1.0.3 (the latest version I have access to) doesn't seem to support popups at all.
Konqueror 3.4.3 (Safari's KHTML sibling) also does not support popups.
Of particular relevance to this discussion: http://blogs.msdn.com/ie/archive/2005/11/21/495507.aspx
Based on the last few comments, I can tell that the common thinking about these issues is leading browser programmers to what *I* consider faulty conclusions. It is sad when the few bad apples spoil things for the good-apple majority. Obviously, the programmers are making these anti-developer changes for the supposed good of the general user and to thwart the purposes of the malicious developers. The unfortunate thing is that now we good, nice, friendly developers can no longer rely on being able to tailor the users' experience according to our desires--we can no longer hide the ugly bits that detract from our aesthetic ideals. Not only that, but the legitimate, legal code we've written in the past will now be intentionally broken, so they'll have not just the ugly extra chrome, but they'll also have scrollbars and/or the content will be hidden. So, if we want our past work to continue to perform to our expectations and represent us well, we'll have to go back and fix all of it to accomodate the newly broken features. Please forgive me for being melodramatic and unhelpful, but it is rather infuriating when it seems that an "easy way out" is being taken at my (and others') expense. And it's bothersome when the browser that should be leading the technological revolution is instead playing follow-the-leader. My opinion is, that if you're concerned about the security of a pop-up window in a browser, you probably shouldn't have clicked the link that opened it in the first place. Firefox has a pop-up blocker with whitelisting, so, effectively, if you're in an insecure pop-up, it's your own fault and you should already be perfectly aware of it. Here are a few other ideas, other than breaking features: 1) Prevent a (javascript opened, chromeless) pop-up from opening another pop-up. 2) Prevent a (statusbarless) pop-up from opening an *external* (offsite) link. 3) Warn the user in either of those cases, in the standard way (info bar) and allow them to override the block. 4) In a (statusbarless) pop-up, immediately (on hover) show tooltip containing the URL of any href on the page There *are* ways to protect the user without breaking anything or making things horribly ugly. You just have to think of them, and implement them... am I repeating myself here? As an aside, another thought i had was, what's to prevent a malicious developer from opening up an altogether *fake popup* and bypassing all your horrible security measures anyway? It could be done such that the type of user you're attempting to protect wouldn't know the difference. That approach might not hit *all* users, but it could hit plenty. At the end I come back to this: your hearts are in the right place, but your heads are leading you in the wrong direction. There are better ways to accomplish your goals than what you've implemented.

UI-visibility-related features items have no more effect, except as a condition for whether to open popup or not,
and related prefs to override them are removed.
https://bugzilla.mozilla.org/show_bug.cgi?id=1507375

also now status bar is shown only when necessary at the bottom left of the screen, so I think this bug doesn't apply to the latest behavior.

Status: REOPENED → RESOLVED
Closed: 19 years ago5 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: