I released a new version of a firefox webextension, Copy
All Tabs last night. The code is open source and available on github.
The new version fixes many bugs and is overall more stable. It works as expected on Windows and Mac (Firefox 61).
However, when I was testing on Linux (both Firefox 60 and 61), the "Copy Tabs" function fails.
https://www.google.com/search?q=Component+returned+failure+code&ie=utf-8&oe=utf-8&client=firefox-b-1-ab
Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE)
The function that fails on Linux is located in this file:
https://github.com/charlesbrandt/copy_all_tabs/blob/master/ff-web_extension/background.js
The major shift was moving the copy and paste functions from a content script that was injected into the active tab's page to the background.js file. The content script approach was failing for Firefox specific pages (e.g. about:debugging) for security reasons.
Given the discrepancy, I'm inclined to think it has something to do with Firefox, but if it's a problem in the webextension I'd be happy to fix it.
If this is a bug in firefox, what is the best way to report it?
Alternatively, does anyone have a suggestion for how modify the extension so that it works effectively on all platforms?
Update:
I followed #Dexter's advice and filed a bug in Bugzilla:
https://bugzilla.mozilla.org/show_bug.cgi?id=1473780
Since that time, the plugin eventually started working in newer versions of the browser.
I do NOT know if this might be your issue, but here goes.
Recently switched from Windows to Pop! OS (derived from Ubuntu/GNOME). Had problems with certain Firefox Browser Extensions, specifically those enabling the copying of links from webpages and subsequent pasting them into, say, GVim.
UNTIL I followed the instructions here:
How to Customize the GNOME Shell in Ubuntu Using Extensions
https://www.makeuseof.com/tag/customize-gnome-shell-extensions/
WRT installing GNOME Tweak, GNOME Shell Extensions, and Shell Extensions for Firefox.
I would suggest you try this and see if it helps. I hope it does.
Related
I have been happily using the Chrome development tools for some five years to debug my Angular/node.js code. I open the Chrome development tools, click on the "sources" tab, navigate my way to the "Webpack" link on the left, and find my way to the directory of all my Javascript source and away we go. Among other matters, the good folk of Chrome have continually improved the debugger over the years: it is a beautiful thing. I have been very happy.
Until this week, when suddenly the Webpack disappeared from the source options. I can see lots else (essentially, all the javascript referenced direct from the index.html file) but the webpack is not there. Nor is it accessible in Safari. But it is still there in Opera and Firefox.
What is going on? I can not be the only person who routinely uses Chrome to debug a webpack application. Help, please.
Here is a screenshot of what I see in my browser. First, as it now appears WITHOUT any Webpack access, in Chrome:
Second, as it still appears in Firefox (and Opera) with Webpack and all my stuff:
Update! I've found the code in Safari. But it no longer appears under the label "Webpack". Instead, it appears under the site URL-->dist-->app.bundle.js (which appears as a folder containing all the code files, thus:
However, app.bundle.js in Chrome is NOT a folder; clicking on it brings up this message:
Yes, I can see that I might here be able to use the "Filesystem" tab to import the files from my development system, and to edit and debug them directly in the debugger while running the app on a local host. Very neat. But actually, there are many times I need to be able to dig inside the app on the production system. I can still do this on Safari, Firefox, Opera. But not now on Chrome. Why not?
UPDATE! I have been digging yet further. Not only is it only Chrome that has this problem. It appears that it is only Chrome on an M1 chip Mac running Big Sur. And digging still deeper: when I look at the app.bundle.js file I discover -- lo and behold! -- all 13000 lines of my code, originally distributed across some 60 component.js files, appears in this one indigestible mega file. Yes, I could find the bit I am working on in there and debug it. So Chrome developers: how come the Safari folks are able to deconstruct app.bundle.js back to the original file structure and you guys cannot?
I'm not a Windows Phone developer, and I want as little to do as possible with anything related to Microsoft. Nonetheless, I need to get my mobile web app running properly on Windows Phone 7. What debugging tools are available for the platform? Something like the Webkit developer tools or Firebug would be ideal, either from the phone itself or more likely, remotely debugging from my computer.
If such a thing doesn't exist, I'd settle for being able to read Javascript error messages, and view the contents of variables using alert() or similar. At this point, all I know is that my JS is failing: I don't know where or why, let alone how to fix it.
My dev computer is running OS X, and I'd really like to be able to use these tools from OS X if possible. Assuming that debugging tools exist (which I really hope they do) are they designed for Windows only? If so, does anyone know how well they would work with Wine or similar?
EDIT: I have a physical Windows Phone 7 device, so I can use that. However, alert() doesn't seem to be working, which is why I'm posting this question. Does alert() normally work on the WP7 browser?
You'll likely find the Mobile Perf Bookmarklet to be the easiest all-in-one tool for testing any mobile device.
Works well on the iPhone/iPad/Samsung Galaxy Tab in my testing so far.
Quote:
It displays a menu with links that load other bookmarklets including Firebug Lite, Page Resources, DOM Monster, SpriteMe, CSSess, and Zoompf.
Unless you have a Windows Phone 7 device, you will need to run Windows in BootCamp and install the Windows Phone Developer Tools in order to test in IE on the emulator. I don't know about Whine, but I ran into major problems trying to test in Parallels - so based on my experience, I suggest keeping it as simple as possible.
There is no console in IE on the phone, so you will need to use alert, like you suggested, or just write text to a div on your page as a custom console.
If you really want to code in OS X (which I definitely understand), using a separate machine for testing IE in the WP7 emulator is going to be your best bet.
EDIT: I just tested alert and it did work fine on my Windows Phone. My guess is that a syntax error is preventing it from calling.
The following may be interesting
Simple IE debug tool for Windows Phone
Supports
Html traversing
Html node styles, properties, metrics
Reading console output
Executing js on device side from console (including intellisense)
Dynamic script injection - ability to debug live sites
Not supported
js breakpoints
Just wanted to add a note to say that full JavaScript debugging is possible now with Windows Phone 8.1 and Visual Studio 2013 Update 2. Full details are available at:
http://blogs.msdn.com/b/visualstudioalm/archive/2014/04/04/diagnosing-mobile-website-issues-on-windows-phone-8-1-with-visual-studio.aspx
I realize that this doesn't help the versions referenced in the original question (WP7), but I'm hoping this will help people who may find this question and are running a more recent version.
Something that has worked for me, is to test my mobile pages through the Windows Vista built-in Internet Explorer browser.
It comes with a script debugger ( which you have to enable in Advanced Options tab through the Internet Options menu ), and it seems that it gets really close to the Internet Explorer Mobile implementation.
Another tip would be, that, instead of using window.alerts, you can also use document.write or set output to a div content.
I'm using this hack to have console.log send info back to the server (it uses window.fetch, which I'm polyfilling, but could use xhr instead) https://gist.github.com/wheresrhys/bf93057ee3a594454582
PLEASE NOTE THAT I HAVE NOW REBUILT MY MACHINE TO REMOVE THIS BUG, SO I CANNOT ANY LONGER VERIFY ANY ANSWERS.
I'm experiencing a problem when attempting to debug javascript using Visual Studio 2008. I've recently installed IE9, but that may not be the cause.
My javascript is in its own separate (.js) file, but whenever I put a breakpoint on a line, it just becomes hollow and says it will not be hit. Then sure enough, it isn't.
I've been into the IE internet options>advanced menu and unchecked the following:
disable script debugging (IE)
disable script debugging (Other)
I've also rebooted my PC. But still the breakpoints are not hit.
Edit: I've just noticed that there are two iexplore.exe entries in the "attach to process" window. That's surely not right! But how do I fix it.
Update:
Other things I've now tried:
Uninstalling IE9 and using IE8 instead.
Unchecking "enable third-party browser extensions" in IE tools>options menu
Try using the javascript key word "debugger;" in the line you want to set the breakpoint. It never fails me. =P
Try disabling third-party browser extensions as per this article.
In IE, go to Tools > Internet Options > Advanced and uncheck Enable third-party browser extensions (requires restart).
Make sure you restart IE.
Well IE has a debugger turned off by default, so try to hit F12 and go to "Script" tab and click "Start Debugging" which will turn the brakepoins on
And the
debugger;
will work only in the "debugging" mode
I know this is old, but try this
http://weblogs.asp.net/abdullaabdelhaq/archive/2009/06/01/VS-Debug-Problem-with-IE8.aspx
It worked for me.
Use a proper browser
I do most of my javascript dev in Firefox with Firebug plugin and Chrome with developer tools (F12).
Firebug particularly is awesome for stepping through code, once you've tried it you wont ever want to use anything else.
You can use Firefox/Firebug in combination with Visual Studio, while this will not let you debug inside your IDE the alternative of using IE is pretty unreliable. You can then debug your JavaScript easily inside the Firefox Browser which provides much better step-by-step debugging support and colour coding for easily identifying javascript objects (arrays, strings, dates, numbers etc).
I have designed a website using Firefox and am now looking to integrate a softphone into the webpage, but unfortunately it is made with ActiveX, so Firefox won't support it.
I have tried opening my page in IE9, and it looks a mess because I've used CSS3 for a lot of it and haven't coded it for different browsers because we will only be using Firefox within the office.
Is there a way that I can tell my page in Firefox to specifically open a new page in Internet Explorer and just have the softphone in there? Or is there a way to get ActiveX running in Firefox with a plugin or something?
You can open a link in Microsoft Edge from any browser by adding microsoft-edge: in front of the url in the HREF.
EDGE (works)
I don't know how to get it to work in other browsers though. My team and I spent quite a bit of time on it and couldn't find a raw HTML/JavaScript solution.
I don't think you can open a IE window from firefox, but you can easily build a firefox plugin based on your activex using http://code.google.com/p/ff-activex-host/
It really depends on your exact situation.
If you are targeting multiple users outside a corporate network this is hardly possible to achieve. However, if you are targeting your company's network it's possible to do this using custom protocol.
Your link then would look like: ie://opens_in_ie.com
You'll have to make changes to registry of target computers though. More info about custom protocols is available here: http://msdn.microsoft.com/en-us/library/aa767914%28v=vs.85%29.aspx
In most cases, system administrator can do this remotely.
IETab V2 will let you open a tab within Firefox that runs the IE engine.
Once installed, you can force a link to open with IE by formatting the URL or bookmark like this:
chrome://ietab2/content/reloaded.html?url=http://domain.com
It's somewhat specific, but I created an internal site at work, and I wanted to link to another internal site that only works in IE. To do this, I created/defined my own application protocol in the registry. Then I added to my links the protocol header. This is similar to what apple does when you click a link and it opens iTunes. The downside to this approach, however, is that users will have to install the registry modification for it to work... like I said, it's really a solution for a very specific scenario.
Same answer as from chuck wallace
If you want to start from for example in Internet Explorer, go to C:\Program Files\Internet Explorer\iexplore.exe and create a shortcut to the Desktop.
When you check the properties from this created shortcut, you will see the Target: C:\Program Files\Internet Explorer\iexplore.exe.
Now you can place the shortcut from the website, behind the Target. It will show something like this: C:\Program Files\Internet Explorer\iexplore.exe www.nu.nl. Or this C:\Program Files\Internet Explorer\iexplore.exe https://stackoverflow.com.
This way it opens IE first and then the website.
I need to debug JavaScript in Internet Explorer 7.
Unfortunately, its default debugger doesn't provide me with much information. It tells me the page that the error showed up on (not the specific script) and gives me a line number. I don't know if that is related to my problem.
It'd be nice if it could narrow down the error to a line number on a specific script (like Firebug can).
Is there an addon to debug JavaScript in IE7 like Firebug does in Firefox?
Thank you!
See also:
Does IE7 have a “developer mode” or plugin like Firefox/Chrome/Safari?
Web Development Helper is very good.
The IE Dev Toolbar is often helpful, but unfortunately doesn't do script debugging
The hard truth is: the only good debugger for IE is Visual Studio.
If you don't have money for the real deal, download free Visual Web Developer 2008 Express EditionVisual Web Developer 2010 Express Edition. While the former allows you to attach debugger to already running IE, the latter doesn't (at least previous versions I used didn't allow that). If this is still the case, the trick is to create a simple project with one empty web page, "run" it (it starts the browser), now navigate to whatever page you want to debug, and start debugging.
Microsoft gives away full Visual Studio on different events, usually with license restrictions, but they allow tinkering at home. Check their schedule and the list of freebies.
Another hint: try to debug your web application with other browsers first. I had a great success with Opera. Somehow Opera's emulation of IE and its bugs was pretty close, but the debugger is much better.
you might want to try
microsoft script debugger
it's pretty old but it's quite useful in the sense if you stumble on any javascript error, the debugger will popup to show you which line is messing up. it could get irrating sometimes when you do normal surfing, but you can turn if off.
here's a good startup on how to use this tool too.
HOW-TO: Debug JavaScript in Internet Explorer
I've found DebugBar.
Not as good as Firebug, but close.
In IE7, you can bring up firebug lite for the current page by pasting the following in the address bar:
javascript:var firebug=document.createElement('script');firebug.setAttribute('src','http://getfirebug.com/releases/lite/1.2/firebug-lite-compressed.js');document.body.appendChild(firebug);(function(){if(window.firebug.version){firebug.init();}else{setTimeout(arguments.callee);}})();void(firebug);
See http://getfirebug.com/lite.html.
Microsoft Script Editor is indeed an option, and of the ones I've tried one of the more stable ones -- the debugger in IE8 is great but for some reason whenever I start the Developer Tools it takes IE8 a while, sometimes up to a minute, to inspect my page's DOM tree. And afterwards it seems to want to do it on every page refresh which is a torture.
You can inspect contents of variables in Microsoft Script editor: if you poke around under Debug > Window you can turn on local variable inspection, watching etc.
The other option, Visual Web Dev, while bulky, works reasonably well. To set it up, do this (stolen from here):
Debugging should be turned on in IE. Go into Tools > Internet Options > Advanced and check that Disable Script Debugging (Internet Explorer) is unchecked and Display a notification about every script error is checked
Create a new empty web project inside of VWD
Right-click on the site in the Solutions Explorer on the top right, go to Browse With and make sure your default browser is set to IE (it's reasonable to assume if you're a web developer IE is not your default browser in which case that won't be the default.. by default)
Hit F5, IE will open up. Browse to the page you want to debug.
VWD will now open up any time you have a script error or if you set a breakpoint in one of the JS files. Debug away!
UPDATE: By the way, if you experience the same slowdowns as me with IE8's otherwise decent debugger, there is a workaround -- if you encounter or make IE encounter an error so that it pops up the "Do you want to debug" dialogue and hit Yes, the debugger will come up pretty much instantly. It seems like if you go "straight" into debugging mode the Dev Tools never inspect the DOM. It's only when you hit F12 that it does.
IE8 has much improved developer tools. Until then it's best to write javascript for firefox first and then debug IE using alert() statements.
Microsoft Script Editor can be used to debug Javascript in IE. It's less buggy than Microsoft Script Debugger but has the same basic functionality, which unfortunately is pretty much limited to stepping through execution. I can't seem to inspect variables or any handy stuff like that. Also, it only shipped with Office XP/2003 for some bizarre reason. More info here if you're game.
I downloaded the Visual Web Developer 2008 Express Edition mentioned by Eugene Lazutkin but haven't had a chance to try it yet. I'd recommend trying that before Script Editor/Debugger.
It's not a full debugger, but my DP_DEBUG extensions provides some (I think) usful functionality and they work in IE, Firefox and Opera (9+).
You can "dump" visual representations of complex JavaScript objects (even system objects), do simplified logging and timing. The component provides simple methods to enable or disable it so that you can leave the debugger in place for production work if you like.
DP_Debug
The IE9 developer tools worked for me. Just set the "Browser Mode" menu item to IE7.
Hey I came across the same problem and found this the application IETESTER. It's pretty awesome, it's an app that has IE 5.5,6, and 7 bundled into it. It doesn't matter what IE version you currently have. This allows you to have multiple versions side by side.
If you enable javascript debugging in IE options and have Visual Studio installed you can even debug the javascript in VS with all the debug options available to you(watches, conditional breakpoints ,etc.)
If you want to start debugging before an error occurs you simply have to put the line
debugger;
into your JS code and this bring you into VS to begin debugging after this statement.
This is absolutely amazing to me for testing backward compatibility for JS code.
Use Internet Explorer 8. Then Try the developer tool.. You can debug based on IE 7 also in compatibility mode
FireBug Lite:
http://getfirebug.com/firebuglite
The answer is simple.
Get Internet Explorer 9
Press F12 to load up Developer Tools
Switch the browser mode to IE7
Running your code through a Javascript static analysis tool like JSLint can catch some common IE7 errors, such as trailing commas in object definitions.
IE8 Developer Tools are able to switch to IE7 mode
If you still need to Debug IE 7, the emulation mode of IE 11 is working pretty well.
Go to menu: Dev Tools, then to emulation and set it.
It also gives error line information.
The following tools works great for me:
1) http://www.debugbar.com/
Provide a convenience UI to with feature like source, style, DOM, Script, HTML check. It also show the actual error in your JS file (which line, which file).
2) http://www.my-debugbar.com/wiki/CompanionJS/Installing
Provide a console for IE6 or IE7 ( which originally does not support)
Screenshot