Broken in beta
Jtasiu opened this issue · comments
Thanks for the report — works for me on 68.0b4. Could you provide steps to reproduce? Also try the latest commit just in case that was the underlying issue.
I recently wanted "local file as new tab" support, and after discovering it had been taken away, I tried this solution today on 67.0 ( 64-bit / Windows ), so I have the latest commit, but it doesn't seem to work... perhaps that's because the "somewhat at random"-selected DOM element relates to a recent XBL change: 'toolbarbutton-badged' is listed at https://bgrins.github.io/xbl-analysis/ as "2019-05-23 Removed binding: toolbarbutton-badged"... perhaps the "hook" on which the trick hangs is now gone?
Maybe I'm just testing it out wrong: in 'userChrome.js', I simply placed a console.log( "foo" ) call as my custom script; I then expected to be able to open a new tab, and look at the console and see my "foo" there.
If the trick depends on "some XBL element", then it's probably going to be non-viable soon, as it looks like XBL is being expunged from the browser.
@nuchi let me know if I can help or provide more details ( or maybe I'm completely missing something? ). :-)
( Also, this will probably complicate things slightly: https://bugzilla.mozilla.org/show_bug.cgi?id=1541233 ).
@psydbernz would you please confirm that (1) you're checking the browser console (ctrl-shift-J) for your "foo" message and not the ordinary web console, and (2) that you're on the latest commit (in case the script caching issue is at play).
Thanks for the links! I'll investigate — when XBL goes away forever then we're out of luck.
I was definitely using the latest commit ( I checked to see that the changes were in place in my local copy of the files ). It turns out I was looking in the wrong place for my "foo" message ( I was looking in the given tab's console ). When I checked the 'Browser Console' window ( CTRL+SHIFT+J ) as you suggested, the message was there. So that's great!
Now the only snag is that it appears the environment is a bit different in userChrome.js context than a typical web page, so something like assigning the "file://" URL to 'window.location.href' replaces the entire browser window ( ! ) with the file. x-D I will have to do some reading on how to manipulate the new tab's contents the right way.
In any case, the trick is still working after all; thanks for putting it up on the Web. :-)
@psydbernz that's the intended behavior — I think what you want can be done with an ordinary extension.
@Jtasiu I'm closing, feel free to reopen if you have more details about how it's not working in v68.