314445 - Dynamically setting direction=up/down on marquee doesn't give complete scroll behavior

Status: REOPENED

(Core :: Layout, defect)

Description

[Martijn Wargers (dead)]

See upcoming testcase.
When clicking on the 'set direction=up' button the marquee changes in a vertical marquee.
But currently it doesn't scroll up completely.
This regressed between 2005-10-26 and 2005-10-28.
It has to be a regression from bug 313642.

Comment 1

[Martijn Wargers (dead)]

Attachment: testcase

Comment 2

[Martijn Wargers (dead)]

Attachment: patch

Ok, backing this part out of the patch fixes the issue.
There might be a better way to fix the issue, though.

Comment 3

[Martijn Wargers (dead)]

On the other hand, this wasn't working well before that checkin.
Click on direction=up, then click on behavior=alternate -> the scrolling isn't correct also.
I bet this has got something to do with this.originalHeight, that only gets set on init().

Comment 4

[j.j.]

testcase WFM (Minefield/3.0a1)

Comment 5

[Martijn Wargers (dead)]

I can still see the bug, using:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061214 Minefield/3.0a1

Comment 6

[j.j.]

Yes, still buggy. I was confused, sorry for the spam.

Comment 7

[j.j.]

Attachment: testcase2 ?

Is this the same bug? (Fx3 and 3.1b1)

Comment 8

[j.j.]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090211 Minefield/3.2a1pre

testcase attachment 201377 [details] WFM (really this time, I hope)

Comment 9

[Martijn Wargers (dead)]

Yeah, but your testcase2 is not working yet, so this bug is not wfm.

Comment 10

[Martijn Wargers (dead)]

So I guess the patch in bug 166591 might have improved the first case, not sure why testcase2 isn't working yet.

Comment 11

[Justin [:JW_SoftvisionQA]]

I can still reproduce this issue shown in TC2. Once the first element hits the top of the window, the whole Marquee restarts at the bottom. Is this an issue that is still going to be fixed or can it be marked as a Wont Fix?

Comment 12

[Martijn Wargers (dead)]

Why would you want to mark it wontfix?

Comment 13

[Justin [:JW_SoftvisionQA]]

I only suggest wontfix because the age of the bug. Also only if, in fact, this issue will not get fixed. Here at Softvision we are tasked with cleaning up all of the older issues.

Comment 14

[Justin [:JW_SoftvisionQA]]

Was able to reproduce on WIndows 8.1 x64 and also Ubuntu 14.04 x32.

Comment 15

[Martijn Wargers (dead)]

Wontfix is for module owners in general.

Comment 16

[Justin [:JW_SoftvisionQA]]

Got ya. For clarity I wasn't going to close this as wontfix just wanted to get the status on this bug due to the age. Sorry for the miscommunication.

Comment 17

[Karl Dubost💡 :karlcow]

It's now working as expected.

Comment 18

[j.j.]

(In reply to Karl Dubost💡 :karlcow from comment #17)

It's now working as expected.

No, testcase2 attachment344086 [details] doesn't work as expected.

Comment 19

[Karl Dubost💡 :karlcow]

Attachment: rendering in browsers

• Left: Blink / Edge Canary Version 90.0.803.0 (Version officielle) Canary (64 bits)
• Middle: Gecko / Firefox Nightly 87.0a1 (2021-02-17) (64-bit)
• Right: WebKit / Safari Tech Preview Release 120 (Safari 14.2, WebKit 16612.1.2.6)

Two differences here:

• Safari and Firefox shares the same scrolling height around ~ 200px
  while Edge shows the full content height
• Safari and Edge scrolls the full content until it reaches the top
  while Firefox stops the scrolling and restart from the bottom as soon as the first line reaches the top.

Reopening indeed (missed that). Thanks j.j.