732905 - "comment" posts on webpages do not appear (in seamonkey), but will in firefox

Status: RESOLVED WORKSFORME

(SeaMonkey :: General, defect)

Description

[pv1nc3nt]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Firefox/10.0.2 SeaMonkey/2.7.2
Build ID: 20120216055339

Steps to reproduce:

I view news items for instance on the www.cbc.ca/news/ webpage, which have a little speech-balloon glyph beneath them which will open the news item with reader comments displayed beneath them.


Actual results:

With SeaMonkey, the page appears the same as if it is opened with the main link, only 
the main article text is visible.


Expected results:

With Firefox, the page opens with main article text visible, but also reader comments below the article. (Have I set something in Seamonkey which is suppressing the comments? I don't know but I can't find anything, and I've looked. I have AdBlock, but I can't see any mischief there. Cookies are set for "session only" in both SM and FF.)

Comment 1

[Philip Chee]

Sorry I can't see any "speech-balloon glyphs" in either Firefox or SeaMonkey. Clicking on any new link brings up the article with comments displayed.

Try clicking on the "View/Hide Comments" underlined link at the bottom of each article.

For example at the bottom of:
<http://www.cbc.ca/news/world/story/2012/03/04/f-mexico-drug-war.html>
I see:

Comments (161) Hide comments

Comment 2

[Phoenix]

WFM too, but comments block loads in ~10 seconds after page load, suspecting waiting for some ad scripts, which blocked by adblock+

Comment 3

[pv1nc3nt]

 Very weird. First, the little glyphs are easy to see under each item here: http://www.cbc.ca/news/ , a square-edged balloon with a number after it, indicating number of comments.

I set adblock+ to disable, first this page, then everywhere, and rebooted the program after each. I still do not see coments after articles, nor do I even see the "View/Hide Comments" link on the page you linked. The link to that article has now dropped off the front page, but picking a current one, if the link itself is mouseovered, it shows the link as http://www.cbc.ca/news/canada/british-columbia/story/2012/03/05/bc-mexico-gangs.html   whereas if the glyph is highlighted, it shows http://www.cbc.ca/news/canada/british-columbia/story/2012/03/05/bc-mexico-gangs.html#socialcomments  , and with firefox this opens the story with comments visible. Seamonkey continues to show no comments in either case. I will try uninstalling adblock+, and failing joy, uninstalling DownLoadHelper, my only other add-on, and report back on results.

Comment 4

[pv1nc3nt]

Well. still no joy: after several tests and reboots, I have completely removed AdBlock+, and DownloadHelper, updated Java and Shockwave flash to the latest, rebooted again, and the situation remains the same: Firefox shows the speech balloons (they sometimes take a second to be rendered) and clicking on them then articles open with a little strip at the bottom showing facebook twitter share email, and beneath that a comments section. Seamonkey on clicking the balloon opens the linked page, bumps the display down to where the comments should start, but neither the little strip of media options nor the comment section appears. If you guys are seeing them, I'm deeply baffled.

Comment 5

[Phoenix]

I'm still not sure, what "speech balloons" is. If you talk about this icons - http://www.cbc.ca/i/news/v10/gfx/icon_a-v.png they doesn't work for me neither in Firefox, nor in IE 8

Comment 6

[therube]

WFM

(a screenshot really would have been nice.  had to go to one of your other links to get a page that actually showed the comment indicator box.)

Once that box is found, it shows a link with an anchor such as #socialcomments, & clicking it loads the page, jumping to the Comments (26) section.


So try Safe Mode.
(Help | Restart with Add-ons Disabled)

If that doesn't work, then disable Plugins from Tools | Add-ons Manager, & then start in Safe Mode.

Comment 7

[therube]

Attachment: Screenshot.

Comment 8

[Philip Chee]

Ah those. It takes a while for those bubbles to appear. WFM on:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120307 Firefox/13.0a1 SeaMonkey/2.10a1

Do you have NoScript (or YesScript) installed?

Comment 9

[pv1nc3nt]

Hi: sorry I have been delayed in responding, it's been busy...
I have a couple of data points: I tried the same tests from a computer 
at work, and got the same result. This was with a XP Pro machine.


I have tried the SafeMode restart,
and captured the result, here:
 http://i35.photobucket.com/albums/d177/PV1/SeaMonkeybugzilla732905_1.png

Upper is SeaMonkey, everything disabled via SafeMode, lower is Firefox.
In both, I clicked on the speech balloon to open the page.
In each case I rolled the view upward a little to capture the bottom of 
the article to provide a bit more context. The page address reads the 
same in each instance, on the address line (I missed capturing it in the 
SeaMonkey capture, sorry).

...Ah, WFM means "worked for me". Well still DWFM. There must be some reason for this - what else is involved here? SeaMonkey's up to date, could it be java or flash - I thought I just updated them, but is there a place to check the version numbers or activations?

Comment 10

[Phoenix]

Ok, it seems that for some reasons scripts, which downloads social data and comments doesn't work in your case in Seamonkey. In Edit - Preferences - Advanced - Scripts & Plugins is Enable JavaScript for Browser enabled?

Comment 11

[pv1nc3nt]

Yes. Lots of other things wouldn't work if that was otherwise, I think.

Comment 12

[pv1nc3nt]

More information: doing "View Selection Source" on the page content, I find the two pages diverge. Selecting a current news item, the source in SeaMonkey goes:

<p>A weather warning is also in place for Haida Gwaii, including heavy snow by Monday evening.</p>



	
					</div>

					
<div class="wrap8 clearfix sclt-share" id="storytools">
	<h3 class="metanav">Share Tools</h3>
	<ul>
		<li><a onclick="location.href=this.href + document.title; return false;" href="/news/feedback/index_typo.html?" class="storytool">Report Typo</a></li>
		<li><a href="/contact/" class="storytool">Send Feedback</a></li>
		<li id="sharetools"/>
	</ul>
</div>

					
<div id="socialcomments"/>
				</div>
				<div id="right">


Whereas in FireFox, it goes:

<p>A weather warning is also in place for Haida Gwaii, including heavy snow by Monday evening.</p>



	
					</div>

					
<div id="storytools" class="wrap8 clearfix sclt-share">
	<h3 class="metanav">Share Tools</h3>
	<ul id="sharetools_gig_containerParent">
		<li><a class="storytool" href="/news/feedback/index_typo.html?" onclick="location.href=this.href + document.title; return false;">Report Typo</a></li>
		<li><a class="storytool" href="/contact/">Send Feedback</a></li>
		<li style="visibility: visible;" id="sharetools"><div class="gig-bar-container gig-share-bar-container">

...FireFox then has a massive amount of code - a block of about 60x250 characters, before it arrives at 

</div>

					
<div id="socialcomments"><div style="height: 100%;" id="sm_2000492657" class="cbccomments show">

...and then launches in to the comments section.

So the first divergence is in the relative order of "wrap8" and "id="storytools"", then SeaMonkey is missing the 
<ul id="sharetools_gig_containerParent">  line, then things realign for a while before going off in completely different directions.

I don't whether this information is helpful at all, but there it is.

Comment 13

[Phoenix]

Ok, let's try other way, save Firebug from here - https://addons.mozilla.org/firefox/downloads/latest/1843/addon-1843-latest.xpi?src=dp-btn-primary
install it via Add-on Manager, after restart enable it with F12 key, switch to Net panel and enable it, select HTML on lower line, and then try to load problem page.
In normal case you should see two lines starting with GET fastbutton?url text and plusone.google.com in Domain column

Comment 14

[Philip Chee]

> More information: doing "View Selection Source" on the page content, I find the two
> pages diverge. Selecting a current news item, the source in SeaMonkey goes:
Aha, Try this:
Edit->Preferences->Advanced->HTTP Networking.
[✓] Advertise Firefox compatibility

Make sure that this box is checked.

Comment 15

[pv1nc3nt]

Hi: OK, three items. I have not yet installed Firebug, but want to report these first. OH, yes, I should mention, SM is 2.7.2, up-to-date so far as I know, but I'm not running betas. FF is 11.0, also up to date. I am on the "release update channel" for both.
1) "Advertise FF compatibility" was not enabled, so I did so.
2) Unfortunately, that did not help (ratz)
3) I booted up the error console windows, both FF and SM. I then set the two browsers each to the main cbc.ca/news page, and cleared the error consoles, then clicked into the "#comments" link to a story identically on the two browsers, and scanned the error console for discrepancies (as usual, SM did not show comments, FF did). The two console reports were identical from the top down, until SM reported these two items which don't appear in the FF console:

Error: uncaught exception: [Exception... "Security error"  code: "1000" nsresult: "0x805303e8 (NS_ERROR_DOM_SECURITY_ERR)"  location: "http://cdn.gigya.com/JS/socialize.js?apikey=2_D_R4jG9HPDjelwI5F2eqWHGI-vMdNUVrQq7THCL2DoR6iDli2OKe-LOznINJv12e Line: 11"]

Error: gigya.services.socialize is undefined
Source File: http://www.cbc.ca/news/canada/toronto/story/2012/03/13/voting-scarborough.html#socialcomments
Line: 1332

It looks to me that this has got to be deeply involved in the problem, as I believe (from the url name and context), that the comments are being handled somehow by "gigya.com" . Can you decypher what this means? Why does SM complain while FF doesn't, and how can I make it stop?

I will now go about installing firebug (to SM, I assume).

Comment 16

[pv1nc3nt]

OK, firebug installed on SM; followed instructions, net is enabled, I opened a page with #comments link. Saw two "get" lines, the first one identical to that shown in the address bar, the second shows 
http://www.cbc.ca/includes/ads/bbframe.html...continuing for half a pagewidth of stuff. In each case, the domain is a numerical IP address, both the same, being for www.cbc.ca.

Comment 17

[Phoenix]

Quick question, in about:config is dom.storage.enabled set to true?

Comment 18

[pv1nc3nt]

It took me a while to figure out what that meant, but I clicked on Help>Toubleshooting Information, and I noticed the address bar said about:support,
so I entered about:config in the address bar, and I found these entries in the page displayed:

dom.server-events.enabled;true
dom.storage.default_quota;5120
dom.storage.enabled;true
dom.workers.enabled;true

then it continues with more dom.workers stuff.

Comment 19

[Phoenix]

Does something changes with SeaMonkey 2.8 out? (I suppose, no, but anyway)
Next thing to check is completely clean profile, use Tools - Switch Profile, create there new profile and check with it, if the problem still there.
Helpful link - http://kb.mozillazine.org/Profile_manager

Comment 20

[pv1nc3nt]

Whoa. Interesting. V2.8 makes no difference, but the new profile I created, works.
Well, I should be able to just migrate to the new profile, and then keep watch for
something corrupting the function of the new profile. I wonder if it is something that got left behind by one of the add-ons I had. I will start digging and see what I find. I will report when/if I determine a cause.

Comment 21

[pv1nc3nt]

OK, I have located the difference: (the new profile has no add-ons at all). It had defaulted to accept cookies. When I set it to accept session cookies, it failed. I then set both SM and FF to "ask every time", and tried again. In this case, I watched every cookie go by, and when it was finished, FF loaded the comments section, but SM did not. There is some difference in how this is being handled between the two.

Comment 22

[pv1nc3nt]

OK, I think I now see what is going on. After a restart of FF, still using cookies "ask every time", I can get it to fail like SM. When I set it back to "discard cookies when FF closes", it works. So I changed the setting in SM from "accept for session only", to accept all, retain for zero days, and now it works too. I would have thought that setting "ask every time" and then answering "allow for session" would be equivalent to setting "discard when FF closes", but apparently it isn't. Similarly, for SM, "allow for session" is not the equivalent of setting "accept and retain for zero days". 
OK, maybe not a bug then, but still a deceptive situation. I wonder how "allow for session" differs from "discard at end of session".