Closed Bug 412324 Opened 18 years ago Closed 18 years ago

Main content panel is not rendered for all WebCT/Blackboard installations

Categories

(Core :: JavaScript Engine, defect)

defect
Not set
major

Tracking

()

VERIFIED FIXED
mozilla1.9beta4

People

(Reporter: henryb, Assigned: crowderbt)

References

()

Details

(Keywords: regression, Whiteboard: DUPEME)

Attachments

(3 files)

User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b2) Gecko/2007121014 Firefox/3.0b2 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b2) Gecko/2007121014 Firefox/3.0b2 Only the header portion of the page is rendered for any WebCT/Blackboard installation (that I have so far tested) in Firefox 3 b2 and b3pre nightly builds. This means that any WebCT pages are unable to be navigated and are generally inoperable which will be critical flaw come release time when students (who are likely early adopters) try to access their course information. This bug is also mentioned in mozilla.feedback here: http://tinyurl.com/yrp7ep Reproducible: Always Steps to Reproduce: 1. Locate an available installation of WebCT/Blackboard. 2. Log in to said installation with a valid username & password. Actual Results: The page is rendered...minus everything below the header portion. Expected Results: The page should be rendered correctly. Attached is a comparison of the page rendered in Firefox 3b2 (or 3b3pre) and in Firefox 2. An openly accessible WebCT installation that demonstrates the same problems is available for testing at http://webct6.govst.edu/webct/entryPageIns.dowebct. Username & password: ecpguest.
OS: Mac OS X → All
Hardware: Macintosh → All
This behavior first appears in the following nightly build for Dec 10, 2007 at 9:14am: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2007/12/2007-12-10-08-trunk/. Any builds after this demonstrate the described behavior. Notably, this is the build immediately before Beta 2 branched. All builds including and prior to the Dec 10, 2007 at 5:16am build (here: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2007/12/2007-12-10-04-trunk/) display the page correctly, as the Firefox 2 Rendering Example shows above. Also...I suspect this occurs with other hardware and operating systems, but I can only test OSX.
OS: All → Mac OS X
Hardware: All → Macintosh
By the way...oops! Ignore the timestamps in the comment above. Just another quick note that this is also present in the latest nightly trunk builds for b3pre.
OS: Mac OS X → All
Hardware: Macintosh → All
From the error console... Error: redeclaration of const Error Source File: http://rpilms.rpi.edu/webct/libraryjs.dowebct?locale=en_US Line: 1145 Error: getApplicationFrame is not defined Source File: http://rpilms.rpi.edu/webct/viewMyWebCT.dowebct Line: 36 Numerous instances of these are repeated throughout the console, from different source files but all with either of the two errors. This is occurring in the latest nightly (buildid: 2008011304).
Version: unspecified → Trunk
I'm still not quite sure where exactly this belongs, but Core->Layout seems to fit this. Reminder note: Details to reproduce this bug at a URL other than the one listed in the main bug are included in the bug Description - please use that site with the username and password mentioned to test this for yourself. This is going to be a problem for college students around the globe if they can't access course information once they upgrade to Firefox 3 (and are forced to go back to something else - IE, Safari, etc.). A large percentage of colleges use WebCT systems to host critical information, so this is not a localized thing. Latest buildid tested: 2008012204 on Mac OS 10.5.1 or 10.5.2 9C20
Status: UNCONFIRMED → NEW
Component: General → Layout
Ever confirmed: true
Product: Firefox → Core
QA Contact: general → layout
Looks like a javascript issue rather than a layout one. Do the errors in the console occur in the older builds? Or do they only start showing up when the bug starts? Bug 376957 was checked in in the timeframe you mention, it looks very suspect.
Assignee: nobody → general
Blocks: 376957
Component: Layout → JavaScript Engine
Flags: blocking1.9?
Keywords: regression
QA Contact: layout → general
Looks like the redefinition of Error is going to be a problem after all. The relevant file is <http://webct6.govst.edu/webct/libraryjs.dowebct?locale=en_US>
The error console messages only appear once the regression range is reached, dolphinling.
We backed off on making standard constructors readonly+don't-delete so this is fixed now. Crowder, can you find the best dup? /be
Whiteboard: DUPEME
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → DUPLICATE
Oh for the love of Pete ... Brian, can you patch jsexn.c to pass 0 instead JSPROP_READONLY | JSPROP_PERMANENT to js_DefineFunction in js_InitExceptionClasses ? /be
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Assignee: general → crowder
Status: REOPENED → NEW
Flags: blocking1.9? → blocking1.9+
Status: NEW → ASSIGNED
Attached patch like soSplinter Review
Attachment #302084 - Flags: review?(brendan)
Attachment #302084 - Flags: review?(brendan)
Attachment #302084 - Flags: review+
Attachment #302084 - Flags: approval1.9+
Comment on attachment 302084 [details] [diff] [review] like so Thanks! /be
When will this be checked in? This whole time I thought it was an issue of blackboard's due to coding not up to standards.
Keywords: checkin-needed
Checking in js/src/jsexn.c; /cvsroot/mozilla/js/src/jsexn.c,v <-- jsexn.c new revision: 3.96; previous revision: 3.95 done
Status: ASSIGNED → RESOLVED
Closed: 18 years ago18 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9beta4
Thanks for the quick fix, everything's up to snuff now. (Verified with the lastest hourly after reed's checkin.)
Can also verify the fix works as indented with the latest hourly. Great job.
Not sure if this bug fix is a part of it.. but as of the latest nightly adblock plus + a webct based site after logging in crashes the browser.
I don't notice anything, Matt, but it would likely be a different problem entirely. File a new bug, I'd say, and we can look at it there because the issue here is fixed. Like I said, though - mine doesn't crash.
/cvsroot/mozilla/js/tests/js1_5/Error/regress-412324.js,v <-- regress-412324.js initial revision: 1.1
Flags: in-testsuite+
Flags: in-litmus-
v
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: