Removing the Field.focus does indeed solve the scrolling issue. That does seem to be a bug, I mean if you focus a field you don't want to scroll to the top do you? How shall we work around this? Conditionally not do the focus if we're on Firefox? Isn't that really ugly? Ideas?
On 10/27/05, Jay Levitt <[EMAIL PROTECTED]> wrote: > Rahul Bhargava wrote: > > > this.form = this.getForm(); > > > > > I'm guessing you've refactored createForm into getForm? What's it look > like? > > > this.element.parentNode.insertBefore(this.form, this.element); > > Field.focus(this.editField); > > // stop the event to avoid a page refresh in Safari > > if(evt) Event.stop(evt); > > }, > >That worked perfectly for me in Firefox and IE on Windows. By > >"perfectly" I mean that it didn't scroll to the top at any point). > > > Switching that to createForm and trying it got me the same problem - > scrolls up. > > >For completeness, anyone got ideas on why the standard arguments var > >check doesn't work? > > > Are you sure that's not just a function of the way .inspect works, vs. the > magic of "arguments"? I see the same thing in an alert or in an inline > debug, but Venkman's watch list shows it normally, and a plain > "alert(arguments.length)" yields "1". > > By sticking alerts on every line, I can see that Firefox scrolls up at > Field.focus(this.editField) - but NOT if it's already shown an alert! So > maybe it is a Firefox bug. But hopefully we can work around it... does this > help any? The problem's apparently not at the end of the routine where we've > been, er, focusing. > > Jay > > > _______________________________________________ > Rails-spinoffs mailing list > [email protected] > http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs > _______________________________________________ Rails-spinoffs mailing list [email protected] http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
