On Wed, Nov 23, 2011 at 10:10:57PM -0500, Jeremy Maitin-Shepard wrote:
> With:
>
> browser_default_open_target = OPEN_NEW_WINDOW;
>
> any sort of content-initiated new window, e.g. target=_blank or window.open()
> from JavaScript, results in no new window being created at all (i.e. the
> attempt to create a new window appears to have no effect), and the following
> error appearing in the jsconsole:
>
> Error: uncaught exception: [Exception... "Component returned failure code:
> 0x80004005 (NS_ERROR_FAILURE) [nsIDOMJSWindow.open]" nsresult: "0x80004005
> (NS_ERROR_FAILURE)" location: "JS frame :: javascript:window.open(); ::
> <TOP_LEVEL> :: line 1" data: no]
>
> It seems possible that the window is being partially created but not shown,
> because after such an error occurs, merely closing the visible windows doesn't
> cause the browser to exit.
>
> I traced the problem to commit b432b8233d98df6aafb2382070cef2f63c239910, which
> attempts to solve the missing scrollbar problem by setting the content type to
> content-primary in window_initialize_late_hook. I assume it is set in the
> hook, as opposed to not at all, specifically to try to avoid the problem I am
> experiencing, but it evidently does not work for me (I have observed this with
> both the release version of firefox-8 as an xulrunner, and also with xulrunner
> 2.0).
>
> Reverting that commit fixes the problem with opening windows; it would
> probably
> also unfix the scrollbar issue if not for my use of the existing workaround:
>
> add_hook("window_initialize_late_hook",
> function(window) {
> window.buffers.get_buffer(0).top_frame.scrollbars.visible = true;
> });
>
>
> I assume since this has gone unnoticed that others aren't experiencing the
> same
> problem, but I wonder why. (Or maybe no one else has
> browser_default_open_target set to OPEN_NEW_WINDOW.)
>
Hi Jeremy,
Let's see if we can come up with a workaround that can be used in
combination with browser_default_open_target = OPEN_NEW_WINDOW. What
results do you get with conkeror HEAD and the following in your rc?
browser_default_open_target = OPEN_NEW_WINDOW;
add_hook("window_initialize_hook", initialize_first_buffer_type);
add_hook("window_initialize_late_hook",
function (window) {
window.buffers.get_buffer(0).top_frame.scrollbars.visible =
true;
});
This sets the browser's type property during the synchonous part of window
init, so Mozilla should be able to find the content-primary browser. The
old scrollbar workaround will also be required with this, I believe.
I am hoping that there is a way that this issue can be a blessing in
disguise, because if I report it in the relevant bugzilla thread as a
demonstration that the current workaround is in error, it just might
inspire Mozilla to FIX THEIR DAMN PLATFORM ALREADY. No, I'm not bitter
about this at all... ;)
--
John Foerch
_______________________________________________
Conkeror mailing list
[email protected]
https://www.mozdev.org/mailman/listinfo/conkeror
