You don't, however, *have* to open it from the console to have it firing away after the window is gone, source of a web page will work just as well.
OS: Linux → All
Hardware: x86 → All
Version: unspecified → Trunk
Does this apply to 1.9.1?
Yes, it applies to 1.9.1, where it's giving me a rash in Thunderbird from seeing one error, wanting to see where it was, getting another error for my troubles.
Assignee: nobody → philringnalda
Status: NEW → ASSIGNED
Attachment #375955 - Flags: review?(gavin.sharp)
Comment on attachment 375955 [details] [diff] [review] Fix Oops, just because I usually only load one document in a viewsource window, doesn't mean it's not possible to have a whole bunch of listeners stacked up waiting for their final fling.
Slightly tacky, but considerably nicer than a try/catch swallowing real errors just to skip that first unload.
Attachment #376019 - Flags: review?(gavin.sharp)
Attachment #376019 - Flags: review?(gavin.sharp) → review+
Yeah, I'd say bug 490071 is almost certainly the answer to my "am I working around something that should be fixed instead?" question. So my next question is, should I check this in anyway? Is one or the other of us more likely to make it to 1.9.1?
You should check this in anyway; you can't know when GC is going to happen.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.2a1
backed out to see if this fixes recent orange http://hg.mozilla.org/mozilla-central/rev/d525ab89ac02
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
The orange in question, for what it's worth, was miscellaneous errors (sometimes timeouts, sometimes test failures, sometimes both) always preceded by: *** 13019 INFO Error: Unable to restore focus, expect failures and timeouts. So far, it looks like the backout may well have fixed it, although we haven't had enough cycles to be sure.
Huh. And does someone have a theory for *how* it might fix it? Keeping in mind that all I touched was viewSource.js, which is only included by viewSource.xul and viewPartialSource.xul, and none of those three files are mentioned directly in any test code, and no test code calls gViewSourceUtils.viewSource(), or .openInInternalViewer(), I'm a bit at a loss as to how I could be causing test failures. Is the theory that... um... we have test code that clicks on a console-error-source link? Or that makes a windowtype="navigator:view-source" (programmatically, and by assembling the pieces, since nothing directly includes the string "navigator:view-source") and then drops something on it?
I think this is clear to reland.
Status: REOPENED → RESOLVED
Closed: 10 years ago → 10 years ago
Resolution: --- → FIXED
Comment on attachment 376019 [details] [diff] [review] Better fix Drivers: I'm ambivalent about the wisdom of taking this untested patch to untested code. The reward (besides the intrinsic reward of getting rid of a 100ms "leak") is skipping half a dozen duplicates when people fail to search for fixed bugs, and skipping a couple dozen "and the error console says 'updateStatusBar is undefined'" "that's meaningless and unrelated" exchanges in bugs about other things. The risk is that some way of getting content in view-source that I can't imagine (and thus wouldn't test even if this had tests) would cause an unload but not a load, and we'd wind up losing the statusbar display of line and column number, unless and until something did load in the window.
Attachment #376019 - Flags: approval1.9.1?
Comment on attachment 376019 [details] [diff] [review] Better fix a191=beltzner
Attachment #376019 - Flags: approval1.9.1? → approval1.9.1+
You need to log in before you can comment on or make changes to this bug.