most likely an uncaught exception in chrome, resulting from |new nsIURI| failing... are there any errors reported in the js console? mvl?
yes Error: uncaught exception: [Exception... "Component returned failure code: 0x804b000a [nsIURI.spec]" nsresult: "0x804b000a (<unknown>)" location: "JS frame :: chrome://browser/content/pref/pref-features.js :: onPopupPrefsOK :: line 179" data: no]
the line is: 134 uri.spec = dataObject.permissions[p].host; and the exception thrown is an NS_ERROR_MALFORMED_URI nsresult. anyway we don't support ports anymore, so maybe we need code to strip the port out of the text string the user enters?
Stripping out ports is fine, as long as I can add a site to allow popups from and it allows popups from all ports on that site, which it corrently does not.
that's because you're using fb0.7. get trunk :) so fb's UI is fundamentally broken here, because it just adds the strings the user enters into a list, and never processes them until the user hits OK. it should at least try to convert them into an nsIURI object at entry time - and throw an error dialog if an exception is caught. that's the only real mechanism for detecting incorrect user input, and fb can't catch it. seamonkey does better; we throw a dialog if the URI had a parse error. mvl, btw, i found a hostPort! http://lxr.mozilla.org/seamonkey/source/xpfe/communicator/resources/content/popupManager.js#331
fyi: that hostPort isn't really critical - but it's inconsistent since if a user enters foo.com:8080 then on pressing 'add' it will still read foo.com:8080, which implies the port has meaning. nicer to rip off the port so it reads foo.com, and then the user knows the port is meaningless ;) mconnor, wanna patch?
Assignee: general → blake
Status: UNCONFIRMED → NEW
Component: Browser-General → General
Ever confirmed: true
OS: Windows XP → All
Product: Browser → Firebird
Hardware: PC → All
Version: Trunk → unspecified
I imagine this will be fixed by the patch for this bug, but I noticed that when entering a site with a port (for example, foo.com:8080) and clicking OK in the Firebird options panel, everything seems to work; the site is added to the list. However, the next time you load the options dialog the entry for that site is at the top of the allowed popups list and simply reads "8080", the domain name has been stripped.
-> me easy enough to handle, and I should be able to make it for 0.8
Assignee: blake → mpconnor
QA Contact: general → bugzilla
Summary: Unable to specify Block PopUp site and port → validate URI on entry when adding to popup whitelist
Target Milestone: --- → Firebird0.8
Created attachment 135459 [details] [diff] [review] patch basically uses a similar process to seamonkey for getting the valid URI out of the entered string. ports are stripped using uri.host (formerly known as uri.hostPort). There's also allowance for something completely failing to get reduced to a URI, whereby there is an error dialog followed by the original dialog for the user to correct the entered value. We will rarely, if ever, hit this, but it will eliminate the potential for the OK button bustage that prompted this bug report.
Status: NEW → ASSIGNED
Summary: validate URI on entry when adding to popup whitelist → Entering an invalid URI for popup whitelist breaks OK button
Will this just fix the problem of adding a site with a port to the list of sites allowed to display popups. Will Firebird actually then allow all popups for the specified (or all ports) of that site, e.g. 8080? Originally, when I had entered the site, without the port 8080, it still blocked port 8080 generated popups.
on trunk, port is no longer relevant for permissions. so mozilla.org in the perms list will allow for mozilla.org:80, :8080, and actually given that its a root domain, bugzilla.mozilla.org too.
Patch checked in. Thanks Mike!
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
Comment on attachment 135459 [details] [diff] [review] patch obsolete review request, patch checked in
Flags: blocking0.8? → blocking0.8+
*** Bug 247447 has been marked as a duplicate of this bug. ***
*** Bug 251486 has been marked as a duplicate of this bug. ***
Status: RESOLVED → VERIFIED
QA Contact: bugzilla → general
You need to log in before you can comment on or make changes to this bug.