None of the modules' documentation loads



Add-on SDK
7 years ago
7 years ago


(Reporter: KWierso, Assigned: wbamberg)


Firefox Tracking Flags

(Not tracked)




(1 attachment)



7 years ago
When loading the documentation from that URL, I get the following error for every single module:

Parse Error in docs/***.md
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>404 Not Found</title> </head><body> <h1>Not Found</h1> <p>The requested URL /sdk/1.0b2/docs/packages/api-utils/docs/ was not found on this server.</p> <hr> <address>Apache/2.2.3 (Red Hat) Server at Port 80</address> </body></html>

(Where "***" is the name of the module)

The 1.0b1 docs still load just fine.
Will, do you know what might be going on here?  It appears to cause errors on the docs hosted on the website:

Comment 2

7 years ago
I'm looking at it. It's a bit hard to tell from that error message alone. 

It looks as if the js in the browser is sending a URL to the server that the server's not able to recognize as a request for a generated piece of a module doc, so it's just treating it as a request for a file. Which fails of course because the file doesn't exist.
Assignee: nobody → wbamberg

Comment 3

7 years ago
Do you know what the process is of taking an SDK release and running the doc server on Could you possibly help me to get a similar environment running here?

Without being able to reproduce it here, it's hard to do more than speculate. 

What should happen:

- main.js should look at '#module/addon-kit/clipboard' and end up asking the server for '/packages/addon-kit/docs/'.

- the server should recognize that it's being asked for a package or module at from the fact that the first part of the path is 'packages' (, lines 305-6)

- the server should recognize that it's being asked for a DIV from the extension (line 220) and generate and return that from a Markdown file located at: <root_dir>/docs/, where root_dir is initialized from the place it found the package: for example '/Users/mozilla/addon-sdk-1.0b2/packages/addon-kit'


7 years ago
Duplicate of this bug: 629977
Zandr: do you have any thoughts on why this might be happening?  Will is having trouble reproducing it (see comment 3).
The docs directory on the server is created by running 'cfx sdocs' and uploading the resulting tarball. 

A quick look at the resultant directory shows (to use clipboard as an example):

So, we don't have

Is sdocs not building the right things?

Comment 7

7 years ago
Thanks Zandr. cfx sdocs is building the right things, but giving them the wrong names :-(

Comment 8

7 years ago
Created attachment 508616 [details] [diff] [review]
Fix names of DIVs exported by sdocs

cfx sdocs called the DIVs it exported '<module_name>.div.html', but main.js was asking for '<module_name>.div'. This patch changes the names of the exported files in line with what main.js expects.

If we wanted to fix the 1.0b2 release without changing the code, renaming the files on the server should also work.
Attachment #508616 - Flags: review?(myk)
Just for the sake of reproducibility, I'd like to re-run cfx sdocs from a specified tag.

After review, could I get such a thing? Once I have that I'll re-upload the docs tarball.
Comment on attachment 508616 [details] [diff] [review]
Fix names of DIVs exported by sdocs

Will: after you check this in, I'll cherry-pick the change to the 1.0b2 branch and then give Zandr a reference to pull.
Attachment #508616 - Flags: review?(myk) → review+
Resolved by checkin in comment 11.
Last Resolved: 7 years ago
Resolution: --- → FIXED
sdocs regenerated and uploaded. Looks to be working, so marking Verified.
You need to log in before you can comment on or make changes to this bug.