When I click an InPlaceEditor field in Firefox 1.0.7, the page scrolls up to the top. That''s disconcerting, and often ends up with the editable field out of the viewable pane. I can duplicate this on both Mac and PC. Is there a way to prevent this? Even the demo at http://wiki.script.aculo.us/scriptaculous/show/Ajax.InPlaceEditor does this. Jay Levitt
Yeah, you''re right! That''s really annoying! Can anyone figure out why it does this? On 10/25/05, Jay Levitt <lists-railspin-Qa00cJl5so0dYYaOPf09RA@public.gmane.org> wrote:> When I click an InPlaceEditor field in Firefox 1.0.7, the page scrolls > up to the top. That''s disconcerting, and often ends up with the > editable field out of the viewable pane. I can duplicate this on both > Mac and PC. Is there a way to prevent this? Even the demo at > http://wiki.script.aculo.us/scriptaculous/show/Ajax.InPlaceEditor does > this. > > Jay Levitt > > _______________________________________________ > Rails-spinoffs mailing list > Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs >
> On 10/25/05, Jay Levitt <lists-railspin-Qa00cJl5so0dYYaOPf09RA@public.gmane.org> wrote: > > When I click an InPlaceEditor field in Firefox 1.0.7, the page scrolls > > up to the top. That''s disconcerting, and often ends up with the > > editable field out of the viewable pane. I can duplicate this on both > > Mac and PC. Is there a way to prevent this? Even the demo at > > http://wiki.script.aculo.us/scriptaculous/show/Ajax.InPlaceEditor does > > this.I think that usually means that the href points to "#" and one of two things: 1) the onclick event handler is not returning false to cancel out the actual link action 2) the onclick event handler is erroring out I haven''t looked at the IPE much, however. -- rick http://techno-weenie.net
> I think that usually means that the href points to "#" and one of two things: > > 1) the onclick event handler is not returning false to cancel out the > actual link action > 2) the onclick event handler is erroring out > > I haven''t looked at the IPE much, however.The thing is, it''s not a anchor, it''s just an onclick handler. But you might be right, I should probably stop the event and return false.
Jon Tirsen wrote:>>I think that usually means that the href points to "#" and one of two things: >> >>1) the onclick event handler is not returning false to cancel out the >>actual link action >>2) the onclick event handler is erroring out >> >>I haven''t looked at the IPE much, however. >> >> > >The thing is, it''s not a anchor, it''s just an onclick handler. But you >might be right, I should probably stop the event and return false. > >That makes sense... I don''t know JS so well, so I can''t code it myself, but if you have a patch (or even a cut & paste) I''m happy to try it here! My app is for a small enough number of users/records that I''m not paginating, and they''re all on laptops. Result: Edit-in-place has become edit-in-some-other-place :) Jay>_______________________________________________ >Rails-spinoffs mailing list >Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org >http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs > >_______________________________________________ Rails-spinoffs mailing list Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
Yeah, it looks like the enterEditMode method needs to add two things:
1) have an argument so that the event can be passed into the method
(this is what bindAsEventListener lets you do)
enterEditMode: function(evt) {
2) probably as the last thing in the method, it should do this:
Event.stop(evt);
return false;
though I''m not sure you even need the return false if you''ve
already
stopped the event
The new method then turns into this I think:
enterEditMode: function(evt) {
if (this.saving) return;
if (this.editing) return;
this.editing = true;
this.onEnterEditMode();
if (this.options.externalControl) {
Element.hide(this.options.externalControl);
}
Element.hide(this.element);
this.form = this.getForm();
this.element.parentNode.insertBefore(this.form, this.element);
Event.stop(evt);
return false;
},
Rahul
________________________________
From: rails-spinoffs-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
[mailto:rails-spinoffs-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org]
On Behalf Of Jay
Levitt
Sent: Tuesday, October 25, 2005 11:36 AM
To: rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
Subject: Re: [Rails-spinoffs] InPlaceEditor scrolls to top in Firefox?
Jon Tirsen wrote:
I think that usually means that the href points to "#" and one
of two things:
1) the onclick event handler is not returning false to cancel
out the
actual link action
2) the onclick event handler is erroring out
I haven''t looked at the IPE much, however.
The thing is, it''s not a anchor, it''s just an onclick handler.
But you
might be right, I should probably stop the event and return false.
That makes sense... I don''t know JS so well, so I can''t code
it myself,
but if you have a patch (or even a cut & paste) I''m happy to try it
here! My app is for a small enough number of users/records that I''m
not
paginating, and they''re all on laptops. Result: Edit-in-place has
become edit-in-some-other-place :)
Jay
_______________________________________________
Rails-spinoffs mailing list
Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
_______________________________________________
Rails-spinoffs mailing list
Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
On 10/26/05, Rahul Bhargava <rahul-NLnzLvfFuBM@public.gmane.org> wrote:> > 1) have an argument so that the event can be passed into the method (this is > what bindAsEventListener lets you do) > > enterEditMode: function(evt) {You''re correct, but sometimes enterEditMode is called without the event argument (from the unit tests for example). So we need to conditionally stop it if it''s not null, like this: if(evt) Event.stop(evt); I''ll incorporate this in a patch and send it to Thomas asap. Thanks for the help everyone! Cheers, Jon
Unfortunately this fix doesn''t seem to work at all. :-( The code was already stopping the event and even when I return false from the function it still scrolls to the top. We''re back to square one. :-( Cheers, Jon On 10/26/05, Jon Tirsen <jon-fQK1VBTDpnXQT0dZR+AlfA@public.gmane.org> wrote:> On 10/26/05, Rahul Bhargava <rahul-NLnzLvfFuBM@public.gmane.org> wrote: > > > > 1) have an argument so that the event can be passed into the method (this is > > what bindAsEventListener lets you do) > > > > enterEditMode: function(evt) { > > You''re correct, but sometimes enterEditMode is called without the > event argument (from the unit tests for example). So we need to > conditionally stop it if it''s not null, like this: > > if(evt) Event.stop(evt); > > I''ll incorporate this in a patch and send it to Thomas asap. > > Thanks for the help everyone! > > Cheers, > Jon >
Hmm... I see your point (that''ll teach me to next time read the code I
add stuff to before emailing). In theory this check should be working:
if (arguments.length > 1) {
Event.stop(arguments[0]);
}
However, it doesn''t (in Firefox and IE on windows). If you do this:
alert(Object.inspect(arguments));
You''ll see that for some reason the "arguments" var
isn''t filled in
(like it should be for a normal function). This might be an artifact of
some JS weirdness because of the bindAsEventListener... I don''t know -
doesn''t really make sense to me. The point is that it doesn''t
seem to
work.
Anyway, if you do this instead, it does work (remove that arguments
check, add in the suggestion made in previous emails):
enterEditMode: function(evt) {
if (this.saving) return;
if (this.editing) return;
this.editing = true;
this.onEnterEditMode();
if (this.options.externalControl) {
Element.hide(this.options.externalControl);
}
Element.hide(this.element);
this.form = this.getForm();
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). I
haven''t tried that on my Mac yet.
For completeness, anyone got ideas on why the standard arguments var
check doesn''t work?
Rahul
-----Original Message-----
From: rails-spinoffs-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
[mailto:rails-spinoffs-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org]
On Behalf Of Jon
Tirsen
Sent: Wednesday, October 26, 2005 8:04 AM
To: rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
Subject: Re: [Rails-spinoffs] InPlaceEditor scrolls to top in Firefox?
Unfortunately this fix doesn''t seem to work at all. :-( The code was
already stopping the event and even when I return false from the
function it still scrolls to the top. We''re back to square one.
:-(
Cheers,
Jon
On 10/26/05, Jon Tirsen <jon-fQK1VBTDpnXQT0dZR+AlfA@public.gmane.org>
wrote:> On 10/26/05, Rahul Bhargava <rahul-NLnzLvfFuBM@public.gmane.org>
wrote:
> >
> > 1) have an argument so that the event can be passed into the method
(this is> > what bindAsEventListener lets you do)
> >
> > enterEditMode: function(evt) {
>
> You''re correct, but sometimes enterEditMode is called without the
> event argument (from the unit tests for example). So we need to
> conditionally stop it if it''s not null, like this:
>
> if(evt) Event.stop(evt);
>
> I''ll incorporate this in a patch and send it to Thomas asap.
>
> Thanks for the help everyone!
>
> Cheers,
> Jon
>
_______________________________________________
Rails-spinoffs mailing list
Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
Rahul Bhargava wrote:>Anyway, if you do this instead, it does work (remove that arguments >check, add in the suggestion made in previous emails): > enterEditMode: function(evt) { > if (this.saving) return; > if (this.editing) return; > this.editing = true; > this.onEnterEditMode(); > if (this.options.externalControl) { > Element.hide(this.options.externalControl); > } > Element.hide(this.element); > this.form = this.getForm(); > 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. >Really? Not me - I get "Error: this.getForm is not a function" on line 502 of controls.js, Firefox 1.0.7. Jay
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
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 <lists-railspin-Qa00cJl5so0dYYaOPf09RA@public.gmane.org> 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 > Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs >
Michael Zachariassen Krog
2005-Oct-26 21:12 UTC
Re: InPlaceEditor scrolls to top in Firefox?
Hum... Just an Idea... Would it work if the focus were made by a setTimeout? Im thinking that since it works if an alert is shown before, maybe all it needs is time to set everything right in the DOM. A setTimeout might do the trick! -Michael Den 26/10/2005 kl. 22.56 skrev Jon Tirsen:> 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 <lists-railspin-Qa00cJl5so0dYYaOPf09RA@public.gmane.org> 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 >> Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org >> http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs >> >> > _______________________________________________ > Rails-spinoffs mailing list > Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs >
Hahaha, this is great! If I use Field.select instead it doesn''t scroll on Firefox, but then it scrolls on Safari. Field.focus doesn''t scroll on Safari but does scroll on Firefox. Ahhrg! Shall we do some conditional browser specific logic? Use select on Firefox and focus on Safari? On 10/27/05, Jon Tirsen <jon-fQK1VBTDpnXQT0dZR+AlfA@public.gmane.org> wrote:> 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 <lists-railspin-Qa00cJl5so0dYYaOPf09RA@public.gmane.org> 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 > > Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs > > >
Ok, browser conditional logic applied, this patch fixes it in Safari and Firefox: http://dev.rubyonrails.com/ticket/2616 Dunno ''bout IE, but nobody uses IE these days do they!? ;-) On 10/27/05, Jon Tirsen <jon-fQK1VBTDpnXQT0dZR+AlfA@public.gmane.org> wrote:> Hahaha, this is great! If I use Field.select instead it doesn''t scroll > on Firefox, but then it scrolls on Safari. Field.focus doesn''t scroll > on Safari but does scroll on Firefox. Ahhrg! > > Shall we do some conditional browser specific logic? Use select on > Firefox and focus on Safari? > > > On 10/27/05, Jon Tirsen <jon-fQK1VBTDpnXQT0dZR+AlfA@public.gmane.org> wrote: > > 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 <lists-railspin-Qa00cJl5so0dYYaOPf09RA@public.gmane.org> 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 > > > Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > > http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs > > > > > >
Oh yeah! That works perfectly! Thanks Michael! Once again, use the latest patch from here: http://dev.rubyonrails.com/ticket/2616 On 10/27/05, Michael Zachariassen Krog <mic-njz39FWuq6g@public.gmane.org> wrote:> Hum... > > Just an Idea... > Would it work if the focus were made by a setTimeout? > Im thinking that since it works if an alert is shown before, maybe > all it needs > is time to set everything right in the DOM. A setTimeout might do the > trick! > > -Michael > > > Den 26/10/2005 kl. 22.56 skrev Jon Tirsen: > > > 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 <lists-railspin-Qa00cJl5so0dYYaOPf09RA@public.gmane.org> 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 > >> Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > >> http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs > >> > >> > > _______________________________________________ > > Rails-spinoffs mailing list > > Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs > > > > _______________________________________________ > Rails-spinoffs mailing list > Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs >
Michael Zachariassen Krog
2005-Oct-26 21:34 UTC
Re: InPlaceEditor scrolls to top in Firefox?
No prob, Jon! :-) Thx for det credits at the ticket! Den 26/10/2005 kl. 23.31 skrev Jon Tirsen:> Oh yeah! That works perfectly! Thanks Michael! > > Once again, use the latest patch from here: > http://dev.rubyonrails.com/ticket/2616 > > On 10/27/05, Michael Zachariassen Krog <mic-njz39FWuq6g@public.gmane.org> wrote: > >> Hum... >> >> Just an Idea... >> Would it work if the focus were made by a setTimeout? >> Im thinking that since it works if an alert is shown before, maybe >> all it needs >> is time to set everything right in the DOM. A setTimeout might do the >> trick! >> >> -Michael >> >> >> Den 26/10/2005 kl. 22.56 skrev Jon Tirsen: >> >> >>> 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 <lists-railspin-Qa00cJl5so0dYYaOPf09RA@public.gmane.org> 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 >>>> Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org >>>> http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs >>>> >>>> >>>> >>> _______________________________________________ >>> Rails-spinoffs mailing list >>> Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org >>> http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs >>> >>> >> >> _______________________________________________ >> Rails-spinoffs mailing list >> Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org >> http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs >> >> > _______________________________________________ > Rails-spinoffs mailing list > Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs >
Now I''m really confused, as I wasn''t having any of those problems. And I didn''t refactor anything... strange. Anyway, glad you guys figured out the problem and solved it! :-) rahul -----Original Message----- From: rails-spinoffs-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org [mailto:rails-spinoffs-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org] On Behalf Of Jon Tirsen Sent: Wednesday, October 26, 2005 5:31 PM To: rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org Subject: Re: [Rails-spinoffs] InPlaceEditor scrolls to top in Firefox? Oh yeah! That works perfectly! Thanks Michael! Once again, use the latest patch from here: http://dev.rubyonrails.com/ticket/2616 On 10/27/05, Michael Zachariassen Krog <mic-njz39FWuq6g@public.gmane.org> wrote:> Hum... > > Just an Idea... > Would it work if the focus were made by a setTimeout? > Im thinking that since it works if an alert is shown before, maybe > all it needs > is time to set everything right in the DOM. A setTimeout might do the > trick! > > -Michael > > > Den 26/10/2005 kl. 22.56 skrev Jon Tirsen: > > > 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 <lists-railspin-Qa00cJl5so0dYYaOPf09RA@public.gmane.org> 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 argumentsvar> >>> 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 > >> Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > >> http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs > >> > >> > > _______________________________________________ > > Rails-spinoffs mailing list > > Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs > > > > _______________________________________________ > Rails-spinoffs mailing list > Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs >_______________________________________________ Rails-spinoffs mailing list Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
Rahul Bhargava wrote:>Now I''m really confused, as I wasn''t having any of those problems. And >I didn''t refactor anything... strange. Anyway, glad you guys figured >out the problem and solved it! > >Then I''m really confused... the latest controls.js in SVN has a this.createForm, but not this.getForm. What exactly are you calling? Jay
Jon Tirsen wrote:>Hahaha, this is great! If I use Field.select instead it doesn''t scroll >on Firefox, but then it scrolls on Safari. Field.focus doesn''t scroll >on Safari but does scroll on Firefox. Ahhrg! > >I know you have a workaround now, but I was still digging to see what caused this, and discovered that it seems to be a Prototype bug! I''m not sure exactly where, yet, but testing.js (attached) uses Prototype, and exhibits the bug in Firefox. testing2.js doesn''t, and doesn''t! Any Prototype experts? ==========================================================================WARNING: This e-mail has been altered by MIMEDefang. Following this paragraph are indications of the actual changes made. For more information about your site''s MIMEDefang policy, contact Jay Levitt <jay-WxwZQdyI2t0@public.gmane.org>. For more information about MIMEDefang, see: http://www.roaringpenguin.com/mimedefang/enduser.php3 An attachment named testing.js was removed from this document as it constituted a security hazard. If you require this document, please contact the sender and arrange an alternate means of receiving it. An attachment named testing2.js was removed from this document as it constituted a security hazard. If you require this document, please contact the sender and arrange an alternate means of receiving it. _______________________________________________ Rails-spinoffs mailing list Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
You''re html got defanged, you should probably send as zip.
Jay Levitt wrote:> I know you have a workaround now, but I was still digging to see what > caused this, and discovered that it seems to be a Prototype bug! I''m > not sure exactly where, yet, but testing.js (attached) uses Prototype, > and exhibits the bug in Firefox. testing2.js doesn''t, and doesn''t!Argh. Never mind. (if the attachments even came through - I seem to be blocking .js.) I had missed one reference to a Prototype function and didn''t catch the JS error. That function was Field.focus(), which of course kicks off the whole bug! If anyone''s curious, the degenerate JS fail case is below. I''ll submit a Firefox bug in the a.m. after I have another look. You can call it with onclick=''enterEditMode(this)''. function enterEditMode(obj) { var form = document.createElement("form"); var editField = document.createElement("input"); form.appendChild(editField); obj.parentNode.insertBefore(form, obj); editField.focus(); };
The patch has been applied. Btw, the unit test now crashes Firefox 1.0.4, I can consistenly reproduce this here. Cheers, Thomas Am 26.10.2005 um 23:31 schrieb Jon Tirsen:> Oh yeah! That works perfectly! Thanks Michael! > > Once again, use the latest patch from here: > http://dev.rubyonrails.com/ticket/2616 >
Wow! Yeah, it crashes 1.0.6 on Mac too. I''ll look into it. On 10/27/05, Thomas Fuchs <t.fuchs-moWQItti3gBl57MIdRCFDg@public.gmane.org> wrote:> The patch has been applied. > > Btw, the unit test now crashes Firefox 1.0.4, I can consistenly > reproduce this here. > > Cheers, > Thomas > > Am 26.10.2005 um 23:31 schrieb Jon Tirsen: > > > Oh yeah! That works perfectly! Thanks Michael! > > > > Once again, use the latest patch from here: > > http://dev.rubyonrails.com/ticket/2616 > > > _______________________________________________ > Rails-spinoffs mailing list > Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs >
Jay Levitt wrote:> Jay Levitt wrote: > > If anyone''s curious, the degenerate JS fail case is below. I''ll > submit a Firefox bug in the a.m. after I have another look. You can > call it with onclick=''enterEditMode(this)''.This is now bug # 31487 in Mozilla bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=314087 Of course, it''s worked around in scriptaculous, but it''s still good to fix the root cause. Interestingly, it''s a little better in Firefox 1.5b2: it flickers without the setTimeout workaround, but doesn''t actually scroll up. Works great with the workaround. Jay