236690 - Help\For Internet Explorer Users displays a blank page

Status: VERIFIED FIXED

(SeaMonkey :: Help Documentation, defect)

Description

[Vedran Miletic]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.7b) Gecko/20040306
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.7b) Gecko/20040306

Help\For Internet Explorer Users, when clicked, displays a blank page.

Reproducible: Always
Steps to Reproduce:
Just click the menu item.
Actual Results:  
Help opens, and blank page is displayed.

Expected Results:  
Help for IE users should be displayed.

Comment 1

[Frederic Bezies]

Could be seen also in firefox 0.8.0+ / WinXP-Sp1 (Mozilla/5.0 (Windows; U;
Windows NT 5.1; en-US; rv:1.7b) Gecko/20040306 Firefox/0.8.0+ (MozJF)) built
from today's source.

But it seems to happen only on first try ?!

Comment 2

[R.J. Keller]

WORKSFORME on 20040306 that I compiled about 15 minutes ago. Build could contain
regressions from a risky patch, but nothing that should effect Help Viewer.

Reporter: Can we get more detailed steps on how to reproduce this or maybe some
extra information to help repro the bug?

BTW, why was QA changed? The reporter of a bug shouldn't be QA Contact.

Comment 3

[Jo Hermans]

Confirmed in (official) build 2004030605 on Mac OS X 10.2.8

Comment 4

[R.J. Keller]

I still can't reproduce this, but others (stephend) can. Does anyone know when
this regression started?

Comment 5

[Stephen Donner [:stephend] Not actively reading bugmail]

http://lxr.mozilla.org/seamonkey/source/extensions/help/resources/content/contextHelp.js#32

the call we make is:

http://lxr.mozilla.org/seamonkey/source/extensions/help/resources/content/helpMenuOverlay.xul#17

 17     <menuitem label="&helpForIEUsers.label;"
 18       accesskey="&helpForIEUsers.accesskey;"
 19       position="2"
 20       oncommand="openHelp('ieusers');" />

Just taking a guess.

Is it this change? Bug 220561

http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=contextHelp.js&branch=&root=/cvsroot&subdir=mozilla/extensions/help/resources/content&command=DIFF_FRAMESET&rev1=1.7&rev2=1.8

Comment 6

[Stephen Donner [:stephend] Not actively reading bugmail]

Error: uri has no properties
Source File: chrome://help/content/help.js
Line: 264

Comment 7

[Stephen Donner [:stephend] Not actively reading bugmail]

261 
262 function loadURI(uri)
263 {
264   if (uri.substr(0,7) != "chrome:")
265     uri = helpBaseURI + uri;
266   const nsIWebNavigation = Components.interfaces.nsIWebNavigation;
267   getWebNavigation().loadURI(uri, nsIWebNavigation.LOAD_FLAGS_NONE, null,
null, null);
268 }

I haven't yet figured out why the variable 'uri' is coming up null yet.

Is this fallout from something Benjamin has changed in chrome?

Comment 8

[R.J. Keller]

stephend: It looks like it is trying to find the topic from the RDF file (which
has the ID of "forieusers"), and it is returning null, therefore passing null to
the function.

display topic is here ->
http://lxr.mozilla.org/seamonkey/source/extensions/help/resources/content/help.js#115

Which is getting the parameter from here ->
http://lxr.mozilla.org/seamonkey/source/extensions/help/resources/content/contextHelp.js#52

which is received from the menuitem. The only explanation is a RDF toc problem,
but the ieusers item is right here ->
http://lxr.mozilla.org/seamonkey/source/extensions/help/resources/locale/en-US/help-toc.rdf#11,
which is where it should read it from. I'll do some more testing/debugging over
the weekend to see if I can find the problem. If anyone finds any leads, please
post a comment to this bug. Maybe I helped someone find a lead.

Comment 9

[Frederic Bezies]

Sorry if it is some "spam", but it is a JS console error I get on first time
when trying to open "Help\For Internet Explorer Users" menu option :

Error: window.XULBrowserWindow has no properties

Hope it helps.

Comment 10

[R.J. Keller]

Reporter, is this problem in Firefox and Seamonkey? That would make things much 
more stranger if it is.

Frederic: Thanks for posting that. I haven't had time to do any debugging on 
this bug. That is an interesting error. It looks like everyone is having 
different problems on difference machines. Are you running firefox or seamonkey?

Comment 11

[Frederic Bezies]

Here is my user agent, you'll have your answer ;o)

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040312
Firefox/0.8.0+

6 hours CVS based build for your info :o)

Comment 12

[Vedran Miletic]

I noticed this in SeaMonkey at first, I'm haven't tried Firefox at all.

Comment 13

[R.J. Keller]

I now see this on Seamonkey (2004031309), but not on Firefox (20040310).

There doesn't seem to be any leads.

Comment 14

[R.J. Keller]

This is getting weirder as time goes by :). I can sometimes reproduce this bug
every odd time I open For IE Users (1st try, 3rd try, etc.) but not on even
times (2nd try, 4th try).

I also see this when opening help through Help -> Help Contents.

Comment 15

[Frederic Bezies]

>This is getting weirder as time goes by :). I can sometimes reproduce this bug
>every odd time I open For IE Users (1st try, 3rd try, etc.) but not on even
>times (2nd try, 4th try).

Exactly what I'm seeing.

This bug is very weird, and always this error in JS Console. Is Firefox cursed ? ;o)

Comment 16

[R.K.Aa.]

*** Bug 237522 has been marked as a duplicate of this bug. ***

Comment 17

[[e-mail]]

Maybe someone's busted RDF.GetDataSourceBlocking? getLink is called
synchronously as the help window opens; I put in a dump in getLink to query the
DS, the resource and the target, and for a resource of
chrome://help/locale/help-toc.rdf#welcome the target was null.

I put in the same dump in onselect_loadURI (which obviously needs to wait for me
to click on the tree) and it returned a target (I didn't bother to query the
value). Note that onselect_loadURI actually cheats and doesn't use raw RDF to
get the target, someone should file a bug on that ;-)

Comment 18

[[e-mail]]

Attachment: Proposed patch

Comment 19

[Axel Hecht]

Comment on attachment 144162 [details] [diff] [review]
Proposed patch

r=me.
bsmedberg changed the tree to load the datasources asynch on modification of
the attribute. So in order to load synch, one has to kick off the load before
modifying the attribute.

Comment 20

[[e-mail]]

Comment on attachment 144162 [details] [diff] [review]
Proposed patch

Trying sr from bug 235866 first as this is a regression from that bug.

Comment 21

[[e-mail]]

Comment on attachment 144162 [details] [diff] [review]
Proposed patch

Needed to fix highly visible help regression - help loads contents but no start
page.

Comment 22

[Asa Dotzler [:asa]]

Comment on attachment 144162 [details] [diff] [review]
Proposed patch

a=asa (on behalf of drivers) for checkin to 1.7

Comment 23

[[e-mail]]

Fix checked in.

Comment 24

[Steffen Wilberg]

This isn't fixed for Firefox yet. If I understand this right, it's covered by
http://mozdev.org/bugs/show_bug.cgi?id=6030 and will be included in the Firefox
Help 1.1 landing before 0.9 ships, see bug 238221 and
http://mozdev.org/bugs/show_bug.cgi?id=5983.

Comment 25

[R.J. Keller]

*** Bug 239648 has been marked as a duplicate of this bug. ***

Comment 26

[Stefan Borggraefe]

*** Bug 239879 has been marked as a duplicate of this bug. ***