User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en; rv:188.8.131.52pre) Gecko/2008101818 Camino/2.0a1 (like Firefox/3.0.4pre) Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en; rv:184.108.40.206pre) Gecko/2008101818 Camino/2.0a1 (like Firefox/3.0.4pre) When trying to access http://www.informatiker.at.tf the new xul-error page complaining about the self-signed certificate comes up. Adding a exception raises the error "The certificate information for “informatiker.at.tf” could not be found. Please reload the page, then try adding the exception again.". This happens every time, the page worked fine with Camino 1.6 and adding the Exception works in FF3. Reproducible: Always Steps to Reproduce: 1. Go to http://www.informatiker.at.tf 2. Click "Add Exception..." 3. "Certificate not found" error. Actual Results: Error Message mentioned above, Page will not load. Expected Results: Adding Exception for this page and load page.
Aside from all the ads (which seem to never cease loading when ad-blocking is on), the main feature of http://www.informatiker.at.tf is <iframe src="https://davinci.khg.jku.at/users/gue/" name="fid1" id="fid1" width="100%" height="100%" marginwidth="0" marginheight="0" frameborder="0"></iframe> which is the site the error page is complaining about ("davinci.khg.jku.at uses an invalid security certificate. The certificate is not trusted because it is self signed."). We seem to be trying to fetch certificate info for the main website (which has none) rather than for the <iframe> that is actually causing the security error. The work-around here is to notice that the site in the location bar and the site mentioned on the error page differ and simply find the source of the <iframe>, load the https site directly, and add the exception there; unfortunately, if you've clicked in the content area, view-source tries to load the source of the <iframe> rather than the source of the page (which sounds like another bug).
Created attachment 405213 [details] [diff] [review] fix (+ cleanup) This fixes the bug by looking up the correct owning URI (approach stolen from core). Incidentally to that: - Makes a new utility function for something I needed and several other spots were already doing, and has those places call the new function. - Removes some code that I discovered is dead while I was looking for anything useful we already had (it was part of the early popup blocking code, but isn't used in the current iteration).
Landed on CVS trunk and CAMINO_2_0_BRANCH.