Closed Bug 494518 Opened 16 years ago Closed 16 years ago

let declaration still getting lost in certain situations

Categories

(Core :: JavaScript Engine, defect, P1)

Product:
Core
Component:
JavaScript Engine
Version:
1.9.1 Branch
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Milestone:
mozilla1.9.1

People

(Reporter: dao, Assigned: brendan)

Details

(Keywords: fixed1.9.1, regression)

Attachments

(2 files)

test
750 bytes, text/html
Details
js shell version of test
504 bytes, text/plain
Details
Attached file test —
+++ This bug was initially created as a clone of Bug #489034 +++ See attached test. For some reason my output function is also failing... ReferenceError: x is not defined, expedcted 0 TypeError: document.getElementById("out") is null Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1pre) Gecko/20090522 Shiretoko/3.5pre
Flags: blocking1.9.1?
Regression or followup-bug blocks regressing or original bug, not vice versa (too bad cloning a bug does it the other way -- seems like the wrong default). /be
Assignee: general → brendan
Blocks: 489034
Status: NEW → ASSIGNED
No longer depends on: 489034
Priority: -- → P1
Target Milestone: --- → mozilla1.9.1
This works for me in tm and m-c tip js shells. Did a fix not make it yet to the 1.9.1 branch, or is this a browser-only bug? /be
Not related to bug 489034 until proven otherwise. Browser only, so probably simply not related. Blocking on the bug Edward filed, which might or might not be the same bug. This bug's testcase has a single let-block binding and it is initialized, but I smell a common underlying problem. I'll decouple if the bugs prove to be independent. /be
No longer blocks: 489034
Depends on: 494544
No longer depends on: 494544
Not the same as bug 494544. More important, WFM in a tm tip firefox build. Can anyone reproduce, in browser or js shell, on tm or m-c? If not, and if it still bites browser 1.9.1, then the fix must be in the mail ;-). Also, if all that holds, a 1.9.1 shell run of the attach js shell test would be good to hear about, confirming that the bug is not browser-only. /be
Indeed the attached HTML testcase fails in my slightly old (I've been holding off on installing an update) nightly m-c build pulled at http://hg.mozilla.org/mozilla-central/rev/0f4de606acd7 but works on my tm tip build (unpatched). I'm gonna mark WFM and let others sort out which patch in tm fixed things (feel free to id the fix and mark FIXED). /be
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
It actually failed with the latest mozilla-central nightly.
With an hourly, which has a tm merge, I get this: expected 0 and got it TypeError: document.getElementById("out") is null which means I need to file a separate bug for the getElementById failure...
Flags: in-testsuite?
Yes, I wasn't sure that "out" was available -- isn't it dogma to use onload or DOMContentLoaded or whatever it's called? /be
Well, it works if I prefix it with <body>. Without it, the script is moved to the implicit head, and the div isn't available at all as the script runs. The div will later be in the implicit body.
filed bug 494558 on that
Flags: blocking1.9.1? → blocking1.9.1+
Works with the latest 1.9.1 hourly. Not sure if fixed1.9.1 is tracked for bugs resolved WFM -- I hope it is.
Keywords: fixed1.9.1
Flags: in-testsuite?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: