457913 - HTML with "position:fixed" "jiggles" when content scrolls under it if certain form inputs are present

Status: RESOLVED FIXED

(Core :: Web Painting, defect)

Description

[Duncan Loveday]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080929032103 Minefield/3.1b1pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080929032103 Minefield/3.1b1pre

In the attached test case, a simple SVG rectangle covers most of the screen and there is a div with style="position:fixed" containing a button. The button in the div partially overlaps with the SVG. When the SVG is scrolled, the portion of the button that overlaps the SVG "jiggles". It always ends up in the right place but it does move about during scrolling.

Reproducible: Always

Steps to Reproduce:
1. Load the attached HTML.
2. Scroll up and down and watch the button move
3.
Actual Results:  
The button moves

Expected Results:  
The button should be a rock of stability

A regression as this does not happen on 3.0.2.

Comment 1

[Duncan Loveday]

Attachment: SVG test case

Comment 2

[Duncan Loveday]

Attachment: HTML test case

Comment 3

[Ria Klaassen (not reading all bugmail)]

Build nr 20080906021517 works and 20080906040037 fails. There seems to be a bunch of GFX Thebes and Layout bugs around that time.

Comment 4

[Duncan Loveday]

Attachment: Better HTML test case

This shows a several things that the previous test case didn't show - (1) that the problem is not just to do with buttons it is also to do with any input control except checkbox and radio; (2) that the input causing the trouble does not have to overlay the SVG; (3) that when it goes wrong it affects any HTML with fixed positioning that overlays the SVG.

When this new test case is loaded it has all different types of input but none of them are overlaying the SVG. You can scroll the SVG up until it meets some text in a position:fixed div to see the bug. Then scroll down again and press all the buttons at the top to hide the text and button based inputs. Scroll down again and it's rock steady.

Comment 5

[Duncan Loveday]

So to summarise, the conditions required to reproduce this are all of

(1) At least one <input> element present with style "position:fixed" and type="text|button|submit|reset|password|file" and NOT style "display:none"

(2) SVG present

(3) Some HTML with style "position:fixed" and overlaying the SVG

Phew

Comment 6

[Robert Longson [:longsonr]]

Attachment: mathml attachment

Comment 7

[Robert Longson [:longsonr]]

Attachment: Better html testcase 2

Comment 8

[Robert Longson [:longsonr]]

Attachment: Better html testcase 2

Comment 9

[Robert Longson [:longsonr]]

As you can see this has nothing to do with SVG. Trying Core->Layout.

Comment 10

[Duncan Loveday]

Attachment: Plain text attachment

Comment 11

[Duncan Loveday]

Attachment: Better HTML test case 3

Yes, this bug affects any object. I was wondering whether the use of XML was significant but it is not - this has a plain text object and still shows the bug.

Comment 12

[Duncan Loveday]

No takers from generic layout, trying Layout: form controls. Also suggesting this should block 3.1 as it is a regression affecting any site using form controls with fixed positioning and objects. How many sites is that....don't know but this bug makes them look terrible.

Comment 13

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I don't see a problem on Mac. Maybe this is platform dependent. Do you still see the bug if the <object> is replaced by an overflow:auto DIV with the content?

Comment 14

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

It looks pretty bad for me on Linux, but it was equally bad in 3.0.  Given that fixing this type of thing is one of the goals of compositor, I'm not sure how much energy we should spend on it now.  Then again, I thought we would just do a repaint in situations like this rather than trying to blit...

Comment 15

[Duncan Loveday]

Attachment: Test case without OBJECT

(In reply to comment #13)
> ... Do you still
> see the bug if the <object> is replaced by an overflow:auto DIV with the
> content?

Robert, yes the same effect, see last attachment

(In reply to comment #14)
> It looks pretty bad for me on Linux, but it was equally bad in 3.0....

Strange as for me it is fine in 3.0.x on Windows but broken in trunk. If it was a platform dependent efect why would you see it on Linux ?

Comment 16

[Duncan Loveday]

Attachment: Test case without OBJECT

This is the right file

Comment 17

[Duncan Loveday]

Does anyone out there understand what changed to make this bug appear on windows in 3.1 when on 3.0 it was not there ? Or why in 3.0 the bug was there in Linux only. Or why in 3.0 and 3.1 the problem is not there on the MAC ? There must be a reason for these things. It's a very noticeable regression on windows.

Comment 18

[Sander]

This was fixed by bug 352093.