This bug in our legacy app is blowing my mind. I don't even know how to describe it to google to search for good help. This is all in Internet Explorer as this older app doesn't support anything else.
I click on the menu (which is in a different frame of a frameset from the main content frame) to load the page.
On the page is a link to download an excel spreadsheet in a separate window with excel (MIME type is application/vnd.ms-excel).
While the link does work, excel issues TWO requests to our servlet without passing the JSESSIONID, which is odd, but the requests don't seem to matter if we just bail out of the request and return nonsense. The file was already downloaded.
BUT WAIT, it gets weirder. If you hit the link TWICE without closing excel, and then try to click anything in the menu frame, the javascript runs, the servlet responds (I can see the right HTML returned in the network tab), but the main content window DOES NOT CHANGE. Clicking something in the main content window DOES work (there's a popup window button).
There are no javascript errors in the console. If I close excel the tab remains unresponsive, but the problem does not affect OTHER browser tabs. Note that it's so dead that clicking the refresh button on the browser does nothing. And yet...the debugger shows js does run, and the main window popup does respond.
I'm mostly confident that this is something to do with the excel. Is there a known bug or something?
Related
I am trying to debug a web page in Firefox v42.0 Windows 10, where that web page goes through a proxy server and has code injected into it inline via <script>...</script> (not including a separate .js file) by the proxy server. When I right-click View Page Source, I see the original page plus the code I expect to see injected (and which is actually running). I also see the injected content in the DOM view of the Inspector tab. And it is also visible in the Network Tab in the Response section. However, when I view the same page in the debugger, the injected code is not visible, as if the page were not running through the proxy server.
Furthermore, if I insert a debugger; statement in the injected code, I do hit the breakpoint, but in the Firefox debugger tab it tells me I'm on line 550 of a file with only 173 lines in it according to Firefox. So I can not step through the code.
When I do the same thing in Chrome, I see what I'm expecting, which is the injected code in my page, and I am able to debug this code without problem.
I have cleared my cache to no effect. I looked at the Network tab and everything looks as expected there.
How and why is Firefox not showing me the actual page in the debugger tab (matching what's in View Source or the DOM view), and not letting me step through the injected code?
There are a few bugs in Firefox that can cause this that I've encountered myself:
A local caching issue which can be solved by first closing the dev tools window, hard-reloading the page (Ctrl/Cmd + Shift + R), then opening the debugger again.
Trying to debug a tab in a container, but the source is showing the page as it would be outside a container. See bug 1375036). This particular case should now be fixed.
Similar to the previous point, the debugger source showing you a slighty/completely different document to the one that's actually currently rendered by the browser. This is due to the fact that the debugger does not have access to the original markup & inline script the browser used to render the current page! Apparently designed that way to be memory efficient, but seems to ignore the fact that a developer wants to use the memory for storing the source, because they want the actual source. See bugs such as 1060732, 1149835, and 1472581.
If this is happening to you try debugging in the default/no container, or just do it in Chrome 🙁. If you can't debug in another browser, at least try a fresh profile before you "refresh" (nuke) Firefox as others suggest. You can do this from the about:profiles page (address must be typed manually or bookmarked), or by opening Firefox with the -P flag and creating a new one. To use those flags, run firefox -P --no-remote from a *nix/Mac terminal or C:\Program Files\Firefox Developer Edition\firefox.exe -P --no-remote from the Windows Run dialogue; the --no-remote flag is not required but allows you to run the new profile alongside your main one, and disregard links clicked in other programs.
The below worked for me
Copy url from address bar and close the tab.
Open the url in private mode, the debugger shows the source.
Close private window and open in default mode, the debugger shows the source now.
Try to refresh Firefox:
"Refresh Firefox
Click the menu button and then click help.
From the Help menu choose Troubleshooting Information.
Click the Refresh Firefox button in the upper-right corner of the Troubleshooting Information page.
To continue, click Refresh Firefox in the confirmation window that opens.
Firefox will close to refresh itself. When finished, a window will list your imported information. Click Finish and Firefox will open."
Check this for more information:
https://support.mozilla.org/en-US/kb/refresh-firefox-reset-add-ons-and-settings
I had the same problem. I solved it following these instructions.
I had a similar issue, but this was due to the index page redirecting to a subdirectory. The subdirectory contained the index.html with the javascript include files. The src files only got displayed only when an error occurred. To get around this, I cleared all my cache and I went directly to the subdirectory.
I have a javascript file that was accidentally added to the admin side of our site. The javascript is below,
<script>
if (document.getElementById("errorTitle") != null && document.getElementById("errorTitle").innerHTML === "Insufficient Privileges") {
window.location.replace("/portal/InsufficientPrivileges");
} else {
window.location.replace("/portal/FileNotFound");
}
</script>
The problem is that this code runs on the admin pages so we are unable to remove it. If we disable javascript on the browser the page never renders, dynamic content. How can we disable this from running so we can upload the proper file?
You might be able to edit the page that contains the reference to the problem file. If you can just edit the page to jump over where that code is called with an if statement or goto.
If you can't edit the other pages then you can Use the debugger to change the code executed on the fly. Chrome and Firefox have debuggers that should be able to do this.
Specifically for Chrome you go into the object inspector (available via menus or right clicking on the page). Then you can see the HTML on the left window. You select the script tag of interest, you can right click and select delete or select "Edit HTML"
If the page redirects you before you're even able to edit anything, you can use automated tools.
Fiddler (Windows)
Fiddler lets you see all pages downloaded, and then you can have it send your browser a different page when it tries downloading any page you specify (AutoResponder feature). This way you can temporarily edit a page while you can fix it in the admin panel.
Greasemonkey (Firefox) or Tampermonkey (Chrome)
These plugins let you run JavaScript code on a page as soon as it gets to your browser. This will let you do things such as removing the script tag programmatically.
I am new on add-on development using the SDK.
I want to ask you guys if it is possible to start my extension automatically after I open my browser? At the moment I starts after I press my widget icon in the toolbar (the panel shows a table with some data I get from the DOM).
Another thing I want to ask you: is it possible to show a loading screen (like a ajax gif) inside my panel (my extension needs a few seconds after switching a tab, to get the DOM data) every time I press the toolbar button.
First of all: One question per post, please.
Extensions are always started with the browser. When it comes to SDK add-ons, your main.js will be called. It's your job to perform any additional initialization form there.
Panels contain regular HTML pages and therefore can use images.
It's impossible to tell you more, without you providing more details and the code you got so far!
ASP.Net Webforms pages are wrapped in a massive form, which restricts other forms on the page because nested forms don't work. This is intentional because in a webforms project, there can only be one form per page, and all of the server/client interaction require it. In order to build a custom form, I put together a modal dialog in this way. In order to allow for proper error messages from the server, my modal dialog has to post back to itself. In order to do this, I followed this trick to use the form target as the name of the window the dialog is in.
The problem comes when I try to add a button to download a file. When I try to download a file from this dialog now, nothing happens. I can redirect my response to the file in question, but I can't write the file to the response because the dialog box just sits there when I click the button and nothing happens.
After quite some time researching and building a small test case, I found out that there are several interesting factors here.
Response.WriteFile() works fine in webforms, even when the form is set with a target of the current window.
Modal dialogs can download files perfectly fine, unless the form is set to the target of the current window.
Through extensive testing, this appears to be an obscure bug, or perhaps even a strange attempt at security. This also appears to be specific to IE 8, though I didn't get to test other versions of IE.
The trick to allowing the download inside the modal dialog is to change the form's target.
function downloader() {
document.getElementById("form1").target = "_blank";
}
This fixes the IE bug and appears to work in all other browsers (though I couldn't get opera to show the pop up at all, even with "allow all popups").
Thought my day of toiling shouldn't go to waste and maybe this will help someone else in the future.
So, I've been creating a site based off a template. The site used to work on IE, but I'm afraid that I have made changes since then that causes everything to go haywire. When first visiting the site my grids and alignments are all off and most of the javascript doesnt work. When I activate scripts and ActiveX all of the elements of the site are invisible except for the background. Though, I can still see the source in this instance.
The site (for now) is: http://www.escroft.com/index(main).html
If the site is not displaying when you turn scripts on, you probably have a script error. Open your developer tools with F12, and reload the page; the console should show you what errors you have, and then you're on your way to fixing them.