148140 - {inc}onClick moves screen but doesn't carry out action

Status: RESOLVED WORKSFORME

(Core :: Layout, defect, P2)

Description

[Jonathan Baron]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc3) Gecko/20020523
BuildID:    2002052316

The first time you click a button, the action,
such as getresp(1,2), if the button says
onClick="getresp(1,2)", is not done.  Instead the
page jumps down.  If you click the same button again,
it works properly.

This may not happen for the first page in the example.
It happens reliably after that page.


Reproducible: Always
Steps to Reproduce:
1. go go url and begin experiment
2. do the first example, starting at the top
3. do the second example


Actual Results:  first click does not record button response,
but moves the screen


Expected Results:  record button response


I can tell the response is not recorded by
looking at the variable called done.  When
the page jumps, this variable has a 0 instead
of a response.  (When you try this, it should
also tell you that you haven't responded.)

Comment 1

[Boris Zbarsky [:bzbarsky]]

To layout.  This is almost certainly a duplicate of other incremental reflow 
bugs....

Comment 2

[Jonathan Baron]

Here is more information about how this bug works.  Go to
http://www.psych.upennn.edu/~baron/pve11a.htm
It is now fixed so that the "Click to go on" button at the bottom
will go on only if your response to the very first button on top
has been recorded.  The other buttons are ignored.

I've also changed the amount of text.  If you set your font so that
the whole page appears on one window, the bug is absent.  Everything
works.  If you set your font larger (or, I suppose, make your window
smaller) so that the right scrollbar appears, the bug is present.

But it is not present the first time.  In order for the bug to be
seen, you have to have scrolled down to the bottom of the screen
on the PREVIOUS screen.  Thus, if you go 1. SMALL FONT, 2. LARGE,
3. LARGE, the bug will appear on #3, because on #2 you did not have
to scroll down to get to the "Click to go on button."  It is as if
the first click tries to restore the scroll position to its previous
state, and, if it can do that, it does it instead of what it is
supposed to do.

I know this is a really minor bug in the big scheme of things, but
it completely prevents me from recommeding Mozilla to the (thousand
or so) people who complete my questionnaires, unless I can find a
workaround.  Now that 1.0 is out, I would really like to do this,
because I do all my testing on Mozilla (and have for some time, even
though most of my subjects use IE).

Comment 3

[Jonathan Baron]

OK.  I found the workaround.  It is to scroll to the top of the
window before I replace it.  You can see the difference between
http://www.psych.upenn.edu/~baron/pve11a.htm
and ...... /pve11b.htm, with the scroll command implemented in the
pve11b and commented out in pve11a.  So I was right about wanting
to return to the previous scroll position of the window.

Also, in today's build (2002062304) I cannot replicate the original
bug in ... /pve11.htm.

So maybe it is really a minor bug.  But, on the other hand, maybe I've
now provided enough information so that someone can fix it without
spending a lot of time on it.  (I wish I could help more, but I don't
know C, just JavaScript.)

Comment 4

[Boris Zbarsky [:bzbarsky]]

Testcase URL is dead, no testcase in bug, marking worksforme.  Please reopen if
you have a testcase that demonstrates this bug; if so, please attach it to the bug.

Comment 5

[Jonathan Baron]

Sorry for removing the test case.  I just tried it again with
the original case, with 2003041233, and it works for me too.
The original case was moved to
http://finzi.psych.upenn.edu/~baron/ex/pve11.htm
if anyone wants to try it (which there is no reason to do).

Comment 6

[Jonathan Baron]

This bug now seems to be back in 1.4b for Linux.  I made a new test case
and put it in http://www.psych.upenn.edu/~baron/tests/ind5a.htm
(which shows the bug) and ...../ind5b.htm
which has the workaround that I found before.

After you read the introduction to the experiment, go to the first screen with
questions and click on some of the buttons.  That works OK.  But then after you
do "click to go on" try it again on the second screen with questions.  Intead
of recording the response (and changing the symbol in the button) the screen
scrolls down.

Comment 7

[Jonathan Baron]

Oops.  I meant 1.4rc1, not 1.4b.

Comment 8

[Devoti Paolo]

see also bug #148140

a similar effect if you open
http://www.mozilla.org/products/thunderbird/
and click knowledge base
not only the link is not followed but page layout changes

Comment 9

[Steve England [:stevee]]

All links are either dead, or their targets have been updates (the thunderbird one in comment 8)
Since there's nothing here to test the reflow branch landing against, and this bug is whiteboard'd with DUPEME, i'm setting INVALID.

Comment 10

[Jonathan Baron]

The latest test cases have been moved (sorry, but I forgot that they were for a bug) to http://finzi.psych.upenn.edu/~baron/ex/emcc/ind5a.htm and ...ind5b.htm.  In the latest build, the bug is gone (although the "workaround" or something like it is still needed in order to get the next page to scroll to the top, but I think I would not call that a "bug").

So I would prefer "resolved" to "invalid", but it doesn't matter.

Comment 11

[Steve England [:stevee]]

Reopening since there is now something to test against.

Comment 12

[Jonathan Baron]

Well, the bug is gone from the current nightly build.  As I said, I just tested it.  What remains should not (I think) be called a bug.  It is reasonable to try to scroll to the position of the previous page, and it has many advantages.  Thus I would favor calling this "resolved," but I'm not going to try to do that.

Comment 13

[Mats Palmgren (inactive)]

WFM, SeaMonkey 2006120701 (pre reflow branch) and 2006120801 (post) on Linux.

When I click on a ">>" button it changes to "++". There is no scrolling
of the page.

Comment 14

[Jonathan Baron]

(In reply to comment #13)
> WFM, SeaMonkey 2006120701 (pre reflow branch) and 2006120801 (post) on Linux.
> 
> When I click on a ">>" button it changes to "++". There is no scrolling
> of the page.

Right.  That is what should happen.  And that is not what DID happen when I reported the bug.  I think this bug is fixed, and I am now going to see if I have the power to mark it as fixed.

Comment 15

[Jason Bassford]

-> WORKSFORME

Comment 16

[Boris Zbarsky [:bzbarsky]]

So... to prevent the "testcase went away" thing we need the following:

1)  The testcase needs to be attached to the bug
2)  The testcase needs to be checked into the regression suite.

Jonathan, could you do #1, please?

Comment 17

[Jonathan Baron]

Attachment: testcase for bug 148140, scrolls with click and doesn't register click

Comment 18

[Jonathan Baron]

Attachment: necessary file for last attachment

Comment 19

[Jonathan Baron]

Attachment: necessary file for last attachment