Closed
Bug 359888
Opened 18 years ago
Closed 18 years ago
Compose page does not come up in Yahoo mail (not beta)
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
VERIFIED
FIXED
People
(Reporter: polidobj, Assigned: sicking)
References
()
Details
(Keywords: regression)
Attachments
(2 files)
104.12 KB,
application/octet-stream
|
Details | |
2.08 KB,
patch
|
jst
:
review+
jst
:
superreview+
|
Details | Diff | Splinter Review |
Going to the compose page in yahoo mail by either clicking compose or replying to an email results in the throbber spinning forever and nothing else happening.
2006110304 works
2006110404 broke
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-11-03+%3A04%3A00%3A00&maxdate=2006-11-04+04%3A00%3A00&cvsroot=%2Fcvsroot
Comment 1•18 years ago
|
||
Most likely a regression from bug 343730, I'd say (bug 358106 would be my next guess). Sicking's on the hook for both :)
Reporter | ||
Updated•18 years ago
|
Component: General → DOM
Product: Firefox → Core
Reporter | ||
Updated•18 years ago
|
Flags: blocking1.9?
Reporter | ||
Updated•18 years ago
|
Assignee: nobody → general
QA Contact: general → ian
Comment 2•18 years ago
|
||
(In reply to comment #1)
> Most likely a regression from bug 343730, I'd say (bug 358106 would be my next
> guess). Sicking's on the hook for both :)
>
I verified this is caused by the checkin for 343730.
The good news is I also verified this issue does not exist on the current branch, which has some of the 343730 code included.
Blocks: 343730
Comment 3•18 years ago
|
||
I did a save as webpage complete of the yahoo mail compose page so this can be worked on - looked at without needing a yahoo account. I will try to find time to get this to a reduced testcase.
Assignee: general → bugmail
Assignee | ||
Updated•18 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 4•18 years ago
|
||
The problem here was the NS_CONTENT_SCRIPT_IS_EVENTHANDLER success value bubbled up into the parser which was unable to deal with it, i.e. it used |== NS_OK| rather than |NS_SUCCEEDED|. Additionally I noticed that bug 343730 "broke" the eventhandler stuff since mIsEvaluated was always true when we got to the code that handled it.
Attachment #246996 -
Flags: superreview?(jst)
Attachment #246996 -
Flags: review?(jst)
Comment 5•18 years ago
|
||
Comment on attachment 246996 [details] [diff] [review]
Patch to fix
// If the script has NOT been executed yet then create a script
// event handler if necessary...
The below code is unconditionally run, so remove the "if necessary" part of that comment.
r+sr=jst with that fixed.
Attachment #246996 -
Flags: superreview?(jst)
Attachment #246996 -
Flags: superreview+
Attachment #246996 -
Flags: review?(jst)
Attachment #246996 -
Flags: review+
Assignee | ||
Comment 6•18 years ago
|
||
Checked in
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 7•18 years ago
|
||
Would be great if someone can verify that this fixes the real yahoo site
Reporter | ||
Comment 8•18 years ago
|
||
VERIFIED with
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061129 Minefield/3.0a1 ID:2006112916 [cairo]
Status: RESOLVED → VERIFIED
(In reply to comment #1)
> Most likely a regression from bug 343730, I'd say (bug 358106 would be my next
> guess). Sicking's on the hook for both :)
>
Updated•6 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•