Problems Posting Replies in Forums (Submit)

[therube]

Problems Posting Replies in Forums (Submit)
- Blocking Refresh on Unfocused Tab related?

NoScript (2.1.0.6rc5) related perhaps?
SeaMonkey 2.1rc1.

Last couple days now.

First noticed yesterday in replying to Bug reports at bugzilla. Happened 3 times.
Today posting a reply at mozillazine. Has happened once now.

Code: Select all

[NoScript] Blocking refresh on unfocused tab, http://forums.mozillazine.org/posting.php?mode=reply&f=6&sid=c4c29485a534e053edbf5fad29763020&t=2202737->http://forums.mozillazine.org/viewtopic.php?f=6&t=2202737&p=10828025#p10828025

Now warnings like that are not necessarily unusual, but what has happened is that (the unusual part) the post did not actually go through.

Yesterday, I didn't correlate the problem to anything in particular, so don't know if EC would have shown related information on the bugzilla page problems?

Twice now, "Saving Changes" on a Bugzilla report has left me here, https://bugzilla.mozilla.org/process_bug.cgi, the screen did not refresh, & checking, my submission did not post. (No such problems days ago or earlier, different location.)

Make that 3 times now. Earlier 2 times, I back-arrowed & Save Changes again. This time I refreshed, accepted the warning & it posted.

[dhouwn]

Was the tab indeed unfocused, eg. because you switched to another tab right after clicking submit, or is the detection maybe not working correctly?

[therube]

Not sure offhand, but thinking it was unfocused.
That's the way I normally do it; post, jump to another message, then jump back to see that things turned out as I wish.

I understand the "Blocking refresh on unfocused tab" behavior & expect it, just wondering if there hasn't been some change, where now the posts are not actually posting - sometimes.

At first was thinking just a networking glitch, but when it happened today, elsewhere, got to thinking perhaps having to do with NoScript?

[Giorgio Maone]

If it was unfocused, that message is granted.
No recent change in that are, anyway.

[therube]

If it was unfocused, that message is granted.

Yes, I understand that.

No recent change in that are, anyway.

OK. I keep my eyes peeled for the next time it happens & see what I make of it.

[therube]

Re: Blocking Refresh on Unfocused Tab

There have been times when a blocked refresh on unfocused tab has not refreshed - ever.
Kind of gets stuck. Not too frequent, but I've seen it.
Sometimes "jiggling" the page gets it to refresh, sometimes not.
(Not really a concern to me.)

In any case, when that happens, even though the page does not refresh (as in it would normally reload the thread at hand), the page itself is never blank, & does include text in the nature of, "This message has been posted successfully.".


Now what I'm seeing recently (& it happened a short while ago at mozillazine), is that the page (after clicking 'Submit' or 'Post' or whatever the button may be) is blank.

So that kind of tells me that what I'm running into is not a 'Blocking Refresh on Unfocused Tab' issue.



With this last incident, there was no NoScript warning in Error Console.
Only this, which I have no idea what it means, when it appeared, or if it might or might not be pertinent.

Code: Select all

Error: 'JavaScript component does not have a method named: "observe"' when calling method: [nsIObserver::observe] = NS_ERROR_XPC_JSOBJECT_HAS_NO_FUNCTION_NAMED

I'll also note that I am not getting any "disconnect" message in Chat, which might denote a networking issue.

[therube]

Just had it happen again on a post "Preview" at dslreports.com.

Nothing in Error Console.

(I'll reboot, but not in a position to do so for a while.)

Oh, & if I View Page Source (of the "blank") page, I"m told "application must send information that will repeat any action ...".
(Can't think what that was called or else I would have written that instead.)


This morning I updated to: Mozilla/5.0 (Windows NT 6.1; rv:2.0.1) Gecko/20110520 Firefox/4.0.1 SeaMonkey/2.1.


I'm going to revert to an earlier NoScript & see if anything changes.

[therube]

<NeilAway> I've seen that before, in my case it's an extension which registers as a startup observer but doesn't actually have an observe method

Edit: Reverted back to 2.1.05, 05/22/2011 15:13.

[therube]

Between mid-day Sunday & now, haven't been able to do much online.

At work I put in the latest #dev, & did very little, without issue (but then it has not manifested itself there).

At home yesterday, I had put 2.1.0.5 back in, & it just happened again, so I'll put the #dev in here, reboot & see how things pan out from there.

I'll also note, that when I clicked 'Submit' it was as if the page (mozillazine) hesitated, longer then it should have, before responding (giving me the blank page).

[therube]

Color me clueless?
Just happened again, this time clicking 'Reply' (@ dslreports.com).
:scratcheshead:
?

[therube]

And again, clicking the "Sign Off" button at BoA.
(Actually I clicked it, opening it in a new tab [which can & does work].)

Something like this:

Code: Select all

https://www.bankofamerica.com/siso/signoff/signoff-default.go?request_locale=en-us&sessionId=....

Now this occurred at work. I'm using SeaMonkey 2.0.14 (the branch), where at home I've been using SeaMonkey 2.1.

So two different browser versions, two different ISP's, most all the same extensions.
Different OS's, W7 (home) & XP (work). Different CPU/mem/video ...

At home 4GB mem, & SeaMonkey is typically using 700 MB - 1 GB of mem.
At work 2GB mem, & SeaMonkey is using ~250 MB ram. (What they call "commit" is 534 MB, so 534 of 2 GB?)

I don't recall this type of thing happening except for the last number of days.

Extensions updated since May are; NoScript, FlashGot, Adblock Plus, Live HTTP Headers. All others have remained the same.

[Giorgio Maone]

Live HTTP Headers

Try uninstalling this (you may want to replace it with HttpFox).

[therube]

Live HTTP Headers (& v0.17 at that)

Since disabling Live HTTP Headers, I have not seen a re-occurrence of this issue.

v0.17 is a relatively new update for me, as are the problems I've described here.
I don't particularly recall this issue when I was using v0.16 (which I've been using for a long time now).

I saw this in both SeaMonkey 2.0.x & 2.1.x, though it was by far more prevalent in 2.1.x.


(I have only used HttpFox in a very limited fashion & not in any of my regular use Profiles.)