Bug 1288 - XUL fails to resolve and connect to URLs
| Summary: | XUL fails to resolve and connect to URLs | ||
| Creator: | disrupted | Date: | 2011-01-21 12:34:38 |
| Project: | K-Meleon | Owner: | desga2 |
| Status: | Open | Severity: | Normal |
| Version: | 1.6b2 | Target Version: | Unknow |
User-agent: K-Meleon/1.5.4
when a url is called using the browser syntax from with a xul/chrome, kmeleon fails to connect to the address and opens an empty window. affects web urls and local calls.
affects extensions like gspace, google sidebar, km sms etc any extension which relies on chrome to resolve and connect a url . could have other implications on XUL performance
tests:
http://kmext.sourceforge.net/tests/xulurl-testlocal.7z
http://kmext.sourceforge.net/tests/xulurl-testweb.7z
tests for local and web addresses, compare performance with 1.5.x, 1.1.x and 1.6 where previous versions are able to resolve the urls, 1.6 fails.
the tests above will create 2 menu entries under tools>
test xul-web url
test xul-local url
this bug affects all 1.6 releases
be advised: for the local url test, the test page (testpage.htm) should be in english default installation path c:\program filesk-meleontestpage.htm
create temporary path where necessary
look at
https://developer.mozilla.org/en/XUL/Attribute/browser.type
"The content that is loaded inside the browser is not allowed to access the chrome above it."
Using browser or iframe 1.6/1.7:
fails using type: content, content-primary, content-targetable
works using type: chrome (default)
Example:
If using type content||content-primary||content-targetable in 1.6/1.7
window.content is null for the document loaded inside the new browser.
In latest nightly Firefox 4.0b9 window.content remains available.
There is no solution while K-Meleon 1.6/1.7 sources are unavailable.
Quickfix:
Change xul type=(content||content-primary||content-targetable) entries to type chrome
or overwrite with XXXXXX (default is chrome).
Related bugs:
http://kmeleon.sourceforge.net/bugs/viewbug.php?bugid=1238
>
Bug confirmed and related with bug 1238 as deadlock indicated above.
But quickfix is not definitive:
"chrome (default behaviour): A browser, intended to be used for loading privileged content using a chrome:// URI. Don't use for content from web, as this may cause serious security problems!"
Like in XUL windows size bug (#1261), we must found what is the reason of the problem to fix it correctly.
[Changed Status from "Unconfirmed" to "Open"]
[Changed Owner from ".Nobody" to "desga2"]