This indeed works as you describe. Arguably there is no point in using the late hook at all. Thanks for looking into it, it would indeed be great if Mozilla just fixed this problem.
On Thu, Nov 24, 2011 at 12:08 AM, John J. Foerch <[email protected]>wrote: > 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
