Closed
Bug 20283
Opened 25 years ago
Closed 25 years ago
Infinite loop when anchor has javascript:history.go(0)
Categories
(Core :: DOM: Core & HTML, defect, P3)
Tracking
()
VERIFIED
FIXED
M18
People
(Reporter: pcurtis, Assigned: radha)
References
()
Details
(Keywords: testcase, Whiteboard: [nsbeta2-][TESTCASE]ETA 7/20[NEED INFO])
Attachments
(3 files)
|
(deleted),
text/html
|
Details | |
|
(deleted),
text/html
|
Details | |
|
(deleted),
patch
|
Details | Diff | Splinter Review |
Steps to Reproduce:
1. Go to http://developer.netscape.com/docs/manuals/dirsdk/jsdk30/index.htm
2. In the left pane, click the arrow icon next to "Step 4" (or 1 or 2 or 3)
3. *crash*
Actual Results: *crash*
Expected Results: Javascript menu expands
Build Date &Platform: 1999111520 Windows NT
Additional Platforms: None, at this time.
Additional Information: none.
|
||
Updated•25 years ago
|
Assignee: mccabe → leger
Component: Javascript Engine → Browser-General
Summary: Browser Crashes on Javascript Menu → Browser Crashes on collapsable menu
|
|
||
Comment 1•25 years ago
|
||
Thanks for finding this bug. Any page we crash on is a problem.
I see no evidence yet that this is actually a problem with the JavaScript
engine. Reassigning to browser-general and changing in the hopes that somebody
from the net can look at it and produce a narrower testcase.
pcurtis - if you can produce a smaller testcase that causes the problem, it'll
be a great help towards actually finding a fix.
(QA - please don't reassign it back to JavaScript without some proof that
something's wrong about how we process JavaScript. If it's a problem with a DOM
api exposed to JavaScript, file it against 'DOM level 0'. )
|
Reporter | |
Comment 2•25 years ago
|
||
Build 1999111520 Linux 2.2.5/glibc 2.1.1 also crashes.
|
||
Updated•25 years ago
|
Severity: normal → critical
Assignee: leger → don
Component: Browser-General → XPApps
QA Contact: rginda → claudius
Re-assinging to the owner of "DOM Level 0" since this has nothing to so with
XPApps. Any idea who should get this?
|
||
Comment 5•25 years ago
|
||
|
|
||
Comment 6•25 years ago
|
||
This line of html is causing the problem:
<A HREF="javascript:history.go(0)">Hello</A>
I attached a test case. This bug shows up all over developer.netscape.com it's
Danny Goodman's html menu code.
I think this is related to javascript: urls not working properly, especially
because this html works fine, which also calls history.go(0):
<html>
<body>
<SCRIPT>
history.go(0)
</SCRIPT>
<A HREF="http://www.yahoo.com/">Hello</A>
</body>
</html>
|
||
Comment 7•25 years ago
|
||
stack trace using build from this morning (winnt). First I assert (follows).
k1 seems bogus (0x0003308c), and thus my guess is the v1 val passed into
js_CompareStrings is bum.
JS_STATIC_DLL_CALLBACK(intN)
js_compare_atom_keys(const void *k1, const void *k2)
{
jsval v1, v2;
v1 = (jsval)k1, v2 = (jsval)k2;
if (JSVAL_IS_STRING(v1) && JSVAL_IS_STRING(v2))
return !js_CompareStrings(JSVAL_TO_STRING(v1), JSVAL_TO_STRING(v2));
if (JSVAL_IS_DOUBLE(v1) && JSVAL_IS_DOUBLE(v2)) {
ASSERT STACK
js_compare_atom_keys(const void * 0x0003308c, const void * 0x00dbcc14) line 132
+ 6 bytes
JS_HashTableRawLookup(JSHashTable * 0x014c6560, unsigned long 1567, const void *
0x0003308c) line 178 + 28 bytes
js_AtomizeString(JSContext * 0x022b1ba0, JSString * 0x00033088, unsigned int 2)
line 488 + 17 bytes
js_AtomizeChars(JSContext * 0x022b1ba0, const unsigned short * 0x01fd47a0,
unsigned int 2, unsigned int 0) line 560 + 19 bytes
js_GetToken(JSContext * 0x022b1ba0, JSTokenStream * 0x01fd44e0) line 703 + 45
bytes
MemberExpr(JSContext * 0x022b1ba0, JSTokenStream * 0x01fd44e0, JSTreeContext *
0x000334b4, int 1) line 2271 + 13 bytes
UnaryExpr(JSContext * 0x022b1ba0, JSTokenStream * 0x01fd44e0, JSTreeContext *
0x000334b4) line 2182 + 19 bytes
MulExpr(JSContext * 0x022b1ba0, JSTokenStream * 0x01fd44e0, JSTreeContext *
0x000334b4) line 2042 + 17 bytes
AddExpr(JSContext * 0x022b1ba0, JSTokenStream * 0x01fd44e0, JSTreeContext *
0x000334b4) line 2024 + 17 bytes
ShiftExpr(JSContext * 0x022b1ba0, JSTokenStream * 0x01fd44e0, JSTreeContext *
0x000334b4) line 2009 + 17 bytes
RelExpr(JSContext * 0x022b1ba0, JSTokenStream * 0x01fd44e0, JSTreeContext *
0x000334b4) line 1977 + 17 bytes
EqExpr(JSContext * 0x022b1ba0, JSTokenStream * 0x01fd44e0, JSTreeContext *
0x000334b4) line 1952 + 17 bytes
BitAndExpr(JSContext * 0x022b1ba0, JSTokenStream * 0x01fd44e0, JSTreeContext *
0x000334b4) line 1940 + 17 bytes
BitXorExpr(JSContext * 0x022b1ba0, JSTokenStream * 0x01fd44e0, JSTreeContext *
0x000334b4) line 1929 + 17 bytes
BitOrExpr(JSContext * 0x022b1ba0, JSTokenStream * 0x01fd44e0, JSTreeContext *
0x000334b4) line 1918 + 17 bytes
AndExpr(JSContext * 0x022b1ba0, JSTokenStream * 0x01fd44e0, JSTreeContext *
0x000334b4) line 1907 + 17 bytes
OrExpr(JSContext * 0x022b1ba0, JSTokenStream * 0x01fd44e0, JSTreeContext *
0x000334b4) line 1896 + 17 bytes
CondExpr(JSContext * 0x022b1ba0, JSTokenStream * 0x01fd44e0, JSTreeContext *
0x000334b4) line 1856 + 17 bytes
AssignExpr(JSContext * 0x022b1ba0, JSTokenStream * 0x01fd44e0, JSTreeContext *
0x000334b4) line 1797 + 17 bytes
Expr(JSContext * 0x022b1ba0, JSTokenStream * 0x01fd44e0, JSTreeContext *
0x000334b4) line 1734 + 17 bytes
Statement(JSContext * 0x022b1ba0, JSTokenStream * 0x01fd44e0, JSTreeContext *
0x000334b4) line 1441 + 17 bytes
js_Parse(JSContext * 0x022b1ba0, JSObject * 0x00ddd2b0, JSTokenStream *
0x01fd44e0, JSCodeGenerator * 0x0003347c) line 283 + 20 bytes
CompileTokenStream(JSContext * 0x022b1ba0, JSObject * 0x00ddd2b0, JSTokenStream
* 0x01fd44e0, void * 0x01fd44e0, int * 0x00000000) line 2263 + 21 bytes
JS_CompileUCScriptForPrincipals(JSContext * 0x022b1ba0, JSObject * 0x00ddd2b0,
JSPrincipals * 0x02b26b04, const unsigned short * 0x02c72a30, unsigned int 13,
const char * 0x00000000, unsigned int 0) line 2342 + 23 bytes
JS_EvaluateUCScriptForPrincipals(JSContext * 0x022b1ba0, JSObject * 0x00ddd2b0,
JSPrincipals * 0x02b26b04, const unsigned short * 0x02c72a30, unsigned int 13,
const char * 0x00000000, unsigned int 0, long * 0x000335f8) line 2702 + 33 bytes
nsJSContext::EvaluateString(nsJSContext * const 0x022b1d30, const nsString &
{...}, void * 0x00ddd2b0, nsIPrincipal * 0x02b26b00, const char * 0x00000000,
unsigned int 0, const char * 0x00000000, nsString & {...}, int * 0x00033958)
line 228 + 53 bytes
nsEvaluateStringProxy::EvaluateString(nsEvaluateStringProxy * const 0x02c71050,
nsIScriptContext * 0x022b1d30, const char * 0x02c72c40, void * 0x00000000,
nsIPrincipal * 0x02b26b00, const char * 0x00000000, int 0, char * * 0x00033954,
int * 0x00033958) line 99 + 54 bytes
XPTC_InvokeByIndex(nsISupports * 0x02c71050, unsigned int 3, unsigned int 8,
nsXPTCVariant * 0x02c72b40) line 139
EventHandler(PLEvent * 0x02c72bf0) line 424 + 41 bytes
nsProxyObject::Post(unsigned int 3, nsXPTMethodInfo * 0x00f2cd80,
nsXPTCMiniVariant * 0x0003377c, nsIInterfaceInfo * 0x02b6b970) line 361 + 9
bytes
nsProxyEventObject::CallMethod(nsProxyEventObject * const 0x02c72dc0, unsigned
short 3, const nsXPTMethodInfo * 0x00f2cd80, nsXPTCMiniVariant * 0x0003377c)
line 391 + 55 bytes
PrepareAndDispatch(nsXPTCStubBase * 0x02c72dc0, unsigned int 3, unsigned int *
0x00033830, unsigned int * 0x0003381c) line 100 + 31 bytes
SharedStub() line 125
Then I crash after "Goto 2" prints out a zillion times in the console. The crash
is in printf :-/. Here's the crash stack.
_write_lk(int 1, const void * 0x0003125c, unsigned int 1) line 129 + 10 bytes
_write(int 1, const void * 0x0003125c, unsigned int 1) line 79 + 17 bytes
_flsbuf(int 71, _iobuf * 0x1025a848) line 183 + 17 bytes
write_char(int 71, _iobuf * 0x1025a848, int * 0x00031304) line 1083 + 75 bytes
_output(_iobuf * 0x1025a848, const char * 0x00376c65, char * 0x00031568) line
393 + 21 bytes
printf(const char * 0x00376c64) line 60 + 18 bytes
nsWebShell::GoTo(nsWebShell * const 0x022a6bb0, int 2) line 2243 + 15 bytes
HistoryImpl::Go(HistoryImpl * const 0x02b27fe4, JSContext * 0x022b1ba0, long *
0x00db328c, unsigned int 1) line 189 + 28 bytes
HistoryGo(JSContext * 0x022b1ba0, JSObject * 0x00dbcc78, unsigned int 1, long *
0x00db328c, long * 0x0003187c) line 342 + 24 bytes
js_Invoke(JSContext * 0x022b1ba0, unsigned int 1, unsigned int 0) line 665 + 26
bytes
js_Interpret(JSContext * 0x022b1ba0, long * 0x00032154) line 2226 + 15 bytes
js_Execute(JSContext * 0x022b1ba0, JSObject * 0x00ddd2b0, JSScript * 0x02c73f70,
JSFunction * 0x00000000, JSStackFrame * 0x00000000, unsigned int 0, long *
0x00032154) line 838 + 13 bytes
JS_EvaluateUCScriptForPrincipals(JSContext * 0x022b1ba0, JSObject * 0x00ddd2b0,
JSPrincipals * 0x02b26b04, const unsigned short * 0x02c72040, unsigned int 13,
const char * 0x00000000, unsigned int 0, long * 0x00032154) line 2705 + 27 bytes
nsJSContext::EvaluateString(nsJSContext * const 0x022b1d30, const nsString &
{...}, void * 0x00ddd2b0, nsIPrincipal * 0x02b26b00, const char * 0x00000000,
unsigned int 0, const char * 0x00000000, nsString & {...}, int * 0x000324b4)
line 228 + 53 bytes
nsEvaluateStringProxy::EvaluateString(nsEvaluateStringProxy * const 0x02c72680,
nsIScriptContext * 0x022b1d30, const char * 0x02c72250, void * 0x00000000,
nsIPrincipal * 0x02b26b00, const char * 0x00000000, int 0, char * * 0x000324b0,
int * 0x000324b4) line 99 + 54 bytes
XPTC_InvokeByIndex(nsISupports * 0x02c72680, unsigned int 3, unsigned int 8,
nsXPTCVariant * 0x02c72150) line 139
EventHandler(PLEvent * 0x02c72200) line 424 + 41 bytes
nsProxyObject::Post(unsigned int 3, nsXPTMethodInfo * 0x00f2cd80,
nsXPTCMiniVariant * 0x000322d8, nsIInterfaceInfo * 0x02b6b970) line 361 + 9
bytes
nsProxyEventObject::CallMethod(nsProxyEventObject * const 0x02c723d0, unsigned
short 3, const nsXPTMethodInfo * 0x00f2cd80, nsXPTCMiniVariant * 0x000322d8)
line 391 + 55 bytes
PrepareAndDispatch(nsXPTCStubBase * 0x02c723d0, unsigned int 3, unsigned int *
0x0003238c, unsigned int * 0x00032378) line 100 + 31 bytes
SharedStub() line 125
|
|
||
Comment 8•25 years ago
|
||
I have no clue what's going on here. Not sure if I'm helping... But my guess is
that JS reflection/stub routines are breaking????
|
||
Updated•25 years ago
|
Summary: Browser Crashes on collapsable menu → [WIP+rods]Browser Crashes on collapsable menu
|
|
||
Updated•25 years ago
|
Assignee: vidur → mscott
Summary: [WIP+rods]Browser Crashes on collapsable menu → Infinite loop when anchor has javascript:history.go(0)
|
|
||
Comment 9•25 years ago
|
||
mscott,
Buster thought you already had this, I can't find your bug. So maybe its a dup
or not. But it goes into an infinite loop becuase of a failure in
nsWebShell::DoLoadURL
|
|
||
Comment 10•25 years ago
|
||
|
|
||
Updated•25 years ago
|
Whiteboard: [TESTCASE] javascript:history.go() broken.
|
||
Comment 11•25 years ago
|
||
Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!
Keywords: testcase
|
||
Updated•25 years ago
|
Target Milestone: M14
|
||
Comment 12•25 years ago
|
||
We can see crash only if we use history.go(0) in Anchor.
If we use it onClick of some button then it does not crash.
Same crash is happening on bug# 22393 too. May be they are related. And bug is
in Anchor.
|
|
||
Comment 13•25 years ago
|
||
Here's the problem:
we run a javascript url for goto anchor(0).
when the url is run, the session history adds the javascript url to it's history
list.
Then the javascript url is executed which says go to anchor 0. Session history
is telling us the url for anchor 0 is the javascript url for going to anchor 0.
hence the infinite loop of loads.
I wonder if the session history shouldn't be adding the current url to the
session history list until after that url is loaded. Actually I would think it
has to do that. Maybe the problem is that the dom JS code proxies an event for
actually running the javascript url. By the time this proxied event gets
executed, the original javascript url has marked itself as done so it gets added
to the sesion history. Then the proxied event gets handled and we read the same
url out of the session history!!
Now that I think about it, I'm sure that's what's actually going wrong.
Just a matter of figuring out how to fix this the right way with session history.
Status: NEW → ASSIGNED
|
||
Comment 14•25 years ago
|
||
I'm not sure what you decided here but please note that indeed Session History MUST add urls before they are necessarily
finished loading. Otherwise, if you follow a link on a page b4 it's done and then click back you get bad things, including a dozen
or so more bugs that were fixed because SH adds the url before it's done loading.
|
|
||
Comment 15•25 years ago
|
||
Apparently session history adds the url to the session history BEFORE we run the
url.
So running a JS url like history.go(0) will always return the same url back out
of the session history causing an infinte loop.
One potential fix is to make sure js urls don't go into session history. I don't
know if we would ever want JS urls going into session history?
Another alternative is to move session history so that urls are only added AFTER
they have been loaded instead of before.
|
|
||
Comment 16•25 years ago
|
||
claudius, thanks for mentioning the problems with moving session history after
the url is loaded. I won't pursue this avenue then. =)
|
|
||
Comment 17•25 years ago
|
||
no prob. In general, I believe session history is somewhat over-inclusive at this juncture. There are open bugs that say
_______url's should not be added to session history. I think law@netscape.com is riding those bugs.
|
|
||
Comment 18•25 years ago
|
||
I should clarify that it isn't session history per say that's causing the
problem. It's something called history in webshell. I'm not sure how mHistory is
different from session history. But before we run a url every URI gets added to
mHistory in PrepareToLoadURI. so javascript:history.go(0) gets added to mHistory
then when that script executes it extracts itself back out and re-runs itself.
|
|
||
Comment 19•25 years ago
|
||
Adding radha to the cc list in case she knows. Radha, do you know what mHistory
is used for in webshell? How does it differ from the session history? mHistory
is adding the javascript:history.go(0) to itself before we run the url. so when
the script gets executed it gets the javascript url out of mHistory and runs it
again. hence the infinite loop.
I can't figure out what mHistory is and how it differs from the session history
which is another variable in webshell.
|
||
Comment 20•25 years ago
|
||
I think mHistory is *global* history.
|
|
||
Comment 21•25 years ago
|
||
Thanks for the info Bill. Properly fixing this bug means changing when urls get
added to *global* history. They should be added after the document has
successfully loaded the url instead of before we load the url. This also makes
the most sense from a design point of view because we don't want to be adding
urls that failed to load or were aborted the global history. we should only add
urls that successfully were loaded.
I think session history should work the same way and it did in mozilla classic.
claudius mentioned that we added the url before it was loaded to session history
in order to fix some problems. I wonder if we shouldn't try to fix those
problems individually instead of moving when the url gets added to the session
history. but that should be another bug.
|
|
||
Comment 22•25 years ago
|
||
There may be some duplication of effort here in the webshell. I currently see a
mHistory which Bill suggested is probably the global history. But there is also
another variable supposedly tracking the global history called mHistoryService
which is an implementation of nsIGlobalHistory.
Ughhh....it almost looks like webshell is implementing 2 separate global
histories + session history.
|
|
||
Comment 23•25 years ago
|
||
*** Bug 28671 has been marked as a duplicate of this bug. ***
|
Assignee | |
Comment 24•25 years ago
|
||
Sorry about the late response. Catching up from sabbatical...
mHistory in Webshell is *NOT* global History. This is the old Session History
code that was used before I wrote nsISession History. It is used by viewer's
back/forward buttons and by javascript for frame history support. It has not
been removed from webshell, because removing it meant hooking viewer and
javascript to nsISH. There was not a lot of interest then in getting rid of this
old code in the webshell world, because we didn't want to hook viewer with nsISH
for simplicity reasons and we didn't want to break the frame history that
javascript maintains.
But NOW with redesigned webshell, Brendan has agreed to hook up javascript with
nsISH and this code will be changing soon....
In short, mHistory is used only by viewer and all javascript history calls.
apprunner doesn't use mHistory.
|
||
Comment 25•25 years ago
|
||
Which Brendan has agreed to do what? I'm on sabbatical (your bug update
generated mail that got through my filters by using "JS" and "brendan"), and not
too likely to fix this soon, or even when I return.
/be
|
|
Assignee | |
Comment 26•25 years ago
|
||
Brendan,
If you recall, you, I and travis had a meeting few months ago and this issue of
hooking up Javascript history with SH came up. It was decided that we will hook
up Javascript history with the window's SH though this may break javascript's
frame history.
I didn't mean to say that *You* were going to hook up. I meant that you agreed
for the hookup of javascript history with SH.
Radha
|
|
||
Comment 27•25 years ago
|
||
Moving my remaining M14 bugs to M15 which is the next targeted milestone.
Target Milestone: M14 → M15
|
|
||
Comment 29•25 years ago
|
||
Fixing JS to use the new session history instead of mHistory may fix this bug
because urls aren't added to the new session history until after we fire the on
load handler. So we won't have this problem where loading the 0th entry in the
on load handler will infinitely cause us to reload the original url.
Radha, do you know who owns the work for moving JS urls to use the session
history instead of mHistory?
|
|
Assignee | |
Comment 30•25 years ago
|
||
I have seen JS's history object to be wired to call docshell which uses the new
session hsitory. But I ran in to some problems because JS urls are parsed as
nsSimpleURLs. Look at http://bugzilla.mozilla.org/show_bug.cgi?id=40160. I'll be
looking in to this later this week. I'll keep you posted.
|
|
||
Comment 31•25 years ago
|
||
Some good news:
1) I made some changes to docshell so we don't actually add the session history
entry to session history until the on load handler is fired in the
OnEndDocumentLoad notification. This fixes this problem.
2) I also have a fix for the assertion problem covered in Bug #40160.
The Bad news:
Right now JS urls which change the window location are badly broken. This is
documented in Bug #37463. We enter a dead lock situation between the file
transport which is blocked waiting for the JS to execute to change the location
and the ui thread which is trying to destroy the file transport channel because
we are going to load a new location.
In short, I have a fix for the infinite loop in this case where the on load
handler tries to load the first entry in session history. But then we run into
Bug #37463.
Marking the dependency.
|
|
||
Comment 32•25 years ago
|
||
|
|
Assignee | |
Comment 33•25 years ago
|
||
I haven't tried your changes yet. But few things that comes to my mind are, what
happens if the page is partially loaded? If the user stopped a load or clicked
on a link before the page is completely loaded, then it gets in to SH. If the
url could not be resolved, then it doesn't. Is this taken care of? I'm not sure
if it is a good idea to add the SHentry from webshell. There is more work to be
done in docshell w.r.t. to SH that myself and the embedding team are working on
right now. I think docshell w'd like to have control of interactions with SH.
Docshell is also specific to each frame, so in a page with frameset, I think
this will be a ugly interaction between webshell and docshell.
|
|
||
Comment 34•25 years ago
|
||
To answer your questions:
1) The OnEndDocumentLoad call is called for loads that get aborted and
interrupted as well. So the url is still correctly added.
>There is more work to be
>done in docshell w.r.t. to SH that myself and the embedding team are working
>on right now. I think docshell w'd like to have control of interactions with >SH.
There is a one to one mapping between webshell and docshell right now. webshell
currently inherits from docshell. Everything you can do in docshell you can do
in webshell. Eventually the OnEndDocumentLoad handler will be moved to docshell
but this hasn't been done yet.
In other words, I don't believe this changes docshell's use of session history
at all. I'm using the same variable mSessionHistory and everything. It just
happens to be that this method is in the derived nsWebShell class.
>Docshell is also specific to each frame, so in a page with frameset, I think
>this will be a ugly interaction between webshell and docshell.
I don't think in this case there is any ugly interaction. Docshell's
implemtation of OnEndDocumentLoad is currently implemented by a sub class:
nsWebshell. The implementation will eventually be moved up to Docshell but that
hasn't happened yet. I don't think "interaction" between webshell and docshell
is an issue here.
I hope this makes sense and alays your fears about the suggested change.
|
||
Comment 35•25 years ago
|
||
Putting on [nsbeta2+] radar for beta2 fix.
QA Contact: claudius → desale
Whiteboard: [TESTCASE] javascript:history.go() broken. → [nsbeta2+][TESTCASE] javascript:history.go() broken.
|
||
Comment 36•25 years ago
|
||
M16 has been out for a while now, these bugs target milestones need to be
updated.
|
|
||
Comment 37•25 years ago
|
||
My proposed fix above is still the only idea I have for a fix (that is not
actually adding the page to the session history until after we have fired an on
load event for the document in the OnEndDocumentLoad).
Radha, I know you are doing lots of new session history bug work for nsbeta2.
Should I re-assign this bug to you or are you okay with the above fix?
I'm currently looking to load balance my nsbeta2 bug list which is currently at
15 so if you have some cycles and want a different fix than the one above I'd
appreciate any help.
|
|
Assignee | |
Comment 38•25 years ago
|
||
taking this from mscott.
Assignee: mscott → radha
Status: ASSIGNED → NEW
|
|
||
Comment 39•25 years ago
|
||
I would not hold nsbeta2 for this bug. I think we can take this off the beta2+
list. Looks like radha has a lot of other more serious bugs to look at anyway.
What do you think Don?
|
|
Assignee | |
Comment 40•25 years ago
|
||
I have fixes for most of my other bugs. This bug does need some research. I will
hold on to this until tuesday or wednesday and then move out if it looks
impossible. Thanks for helping out, mscott :)
Status: NEW → ASSIGNED
|
|
Assignee | |
Updated•25 years ago
|
Whiteboard: [nsbeta2+][TESTCASE] javascript:history.go() broken. → [nsbeta2+][TESTCASE] javascript:history.go() broken. ETA 7/20
|
||
Comment 41•25 years ago
|
||
note: there's no more infinite loop. So this isn't going to cause a freeze or
crash anymore.
|
|
Assignee | |
Comment 42•25 years ago
|
||
can you change the summary to whatever symptoms you are seeing right now?
|
||
Comment 43•25 years ago
|
||
If there's no more infinite loop or crash, then I'm making this "nsbeta2-".
Whiteboard: [nsbeta2+][TESTCASE] javascript:history.go() broken. ETA 7/20 → [nsbeta2-][TESTCASE] javascript:history.go() broken. ETA 7/20
|
||
Comment 44•25 years ago
|
||
nav triage team:
[NEED INFO]
QA please test original bug and close if you can. If you need to create a new
bug for how this bug has evolved, please do.
No longer depends on: 18321
Whiteboard: [nsbeta2-][TESTCASE] javascript:history.go() broken. ETA 7/20 → [nsbeta2-][TESTCASE]ETA 7/20[NEED INFO]
|
|
Assignee | |
Comment 46•25 years ago
|
||
*** Bug 33311 has been marked as a duplicate of this bug. ***
|
|
Assignee | |
Comment 47•25 years ago
|
||
This got fixed with my checkins yesterday. THe mnu does come up. Fixed in branch
too.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•