User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031020 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031020 If the page being veiwed was created using POST data, the link in the JavaSript Console brings up incorrect source for the page being viewed. The link includes strictly the URL, but ignores any data POST-ed to the page. This seems to be the same problem we had in early versions of Mozilla when viewing the source of a dynamically created page was displaying the incorrect source. Reproducible: Always Steps to Reproduce: 1. Look at a page that was dynamically created using POST data from a form and has JavaScript errors. 2. Bring up the JavaSript Console. 3. Click on the URL displayed under the error in the JavaScript Console. Actual Results: The source code in the View Source Window is not of the page that created the JavaSript error. Expected Results: Display the correct source code of the page by POST-ing the form information back to the URL when clicking on the link in the JavaScript Console.

Unfortunately, the JS console has no access to the actual page the error was posted from. All it's given is the URL. It's not given the postdata or a cache entry or anything. So the absolute best it can do is to open up the source for that URL... The problem with passing anything else (document objects, docshells, history entries, etc) to the console is that things will have to stay in memory as long as the error is posted to the JS console, then.... brendan? Thoughts?

How about using the cache (and we should be caching all generated pages via wyciwyg: URLs -- I believe we are caching only those generated entirely via document.write, not those generated partly, and not those generated via javascript: URLs -- jst correct me if I'm wrong)? /be

wyciwyg URLs would not help the situation. the problem is that you can have multiple different responses each time a form post is made. we keep all versions in the cache (subject to cache eviction policy). responses to a form post are stored with a key composed of the URL + a unique identifier. (the unique identify is actually an integer that is incremented with each form post; its initial value is the session start time.) nsICachingChannel provides an accessor to this secondary cache key, and it is currently used in response to the user navigating the View -> Page Source menu item. without that secondary cache key, there is no hope of solving this bug. perhaps the JS console can iterate over the set of current docshells looking for a matching URL, and then it could extract the secondary cache key from the docshell. sounds really ugly :( see nsIWebPageDescriptor, which nsDocShell implements.

i meant to add that even wyciwyg URLs have a counter embedded in them, for example: wyciwyg://x/http://blah.com/ where x is some integer.

My parenthetical aside about wyciwyg: URLs didn't say they'd be useful for form post response pages. I was trying to cover the JS-generated page case. The counter in wyciwyg: URLs should not matter, provided (as with wysiwyg: URLs from Nav 3.x and 4.x) it uniquely identifies the "generation" produced by a page that generates its content (partly or completely) via JS -- it's a generation number. If so, then for this JS console case, in the sub-case where the error is in a generated page, we'll need the right wyciwyg: URL. This sounds do-able with some work, at least for the form-post-response and JS-generated cases. If the entry is evicted, you lose, but if you really care about the JS error, you'll have to click on the console before doing anything that might cycle the cache. Confirming. /be

MASS-CHANGE: This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

The Error Console has been removed in favor of the Browser Console (see Bug 1278368), and the component is going to be removed. If this bug is also relevant in the Browser Console, please reopen and move this into Firefox -> Developer Tools: Console.

I am mass-reopening and re-componenting every single one of the Toolkit:Error Console bugs that appear to have been closed without anyone even *glancing* at whether they were relevant to the Browser Console. If you want to close a whole bunch of old bugs -- FOR ANY REASON -- it is YOUR RESPONSIBILITY to check EVERY SINGLE ONE OF THEM and make sure they are no longer valid. Do not push that work onto the bug reporters. (It's okay to close bugs that haven't been touched in years when they don't have enough information for you to figure out whether the problem is still relevant to the current software - the reporter probably isn't coming back to clarify. But that is the ONLY situation where it is okay.) (I'm going to have to do this in two steps because of the way the "change several bugs at once" form works. Apologies for the extra bugspam.)

The Error Console feature was removed entirely from the tree in Bug 1278368 and the bugzilla component is now being removed. We’ve migrated bugs that seem to also affect the Browser Console into the devtools component, please move this over if it was missed.

This bug is totally relevant to the developer tools console and the browser console last I checked... Just not very easy to fix, especially with the way the console and source viewer stuff interacts. :(