45095 - Semi-transparent HTML form textfields have rendering errors

Status: VERIFIED WORKSFORME

(Core :: Layout: Form Controls, defect, P3)

Description

[Taras Tielkes]

A semi-transparent textfield (on Windows) has a too thin upper border when
initially rendered. When the text inside is modified, the textfield is
re-rendered in a correct way.

Comment 1

[Taras Tielkes]

Attachment: Testcase: HTML file with one semi-transparent textfield.

Comment 2

[Taras Tielkes]

This also applies to TEXTAREA form elements.

Comment 3

[Taras Tielkes]

Similar (but not the same) behaviour seen on Linux; textfield borders are
completely missing. Changing plaf/OS to All/All

Comment 4

[Taras Tielkes]

Textfield doesn't event show with a 26 aug nightly build.

Comment 5

[Marc Attinasi]

I see the textfield fine, but I don't see any border, even after entering text.

Over the HTML Form Controls...

Comment 6

[rods (gone)]

reassigning & futuring

Comment 7

[Taras Tielkes]

Attachment: Corrected testcase

Comment 8

[Taras Tielkes]

The second testcase is updated to reflect the new "-moz-opacity" syntax. I also
have added a background-color style to the textfield so it can be found more
easily on Windows.

Comment 9

[Taras Tielkes]

Tried the second, updated testcase on Linux. Looks similar, the borders of the
textfield are missing. When I try to enter a lot of characters into the
textfield I see two things:
1) the text in the textfield seems to move up and down a pixel while characters
are added.
2) After some seconds, I get a segfault.

Comment 10

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

This seems to work fine for me. Unfortunately I'm not sure which of the 
uncommitted fixes in my tree is responsible, but I suspect it's the new view 
manager.

Comment 11

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

Attachment: Screenshot of the initial rendering in Windows, using my build

Comment 12

[Taras Tielkes]

Robert, that sure looks better, but what is that extra red bar under the textfield?

Comment 13

[Taras Tielkes]

Attachment: Third testcase (shows disappearing border)

Comment 14

[Taras Tielkes]

I have attached a third attachment. The only difference between the 2nd and t
this 3rd, is that this one also contains a single character in the DIV that also
contains the textfield. This seems to cause the border of the textfield to be
painted (at least on Win32, using a 10 sept. nightly build).

When you start to type in the textfield, the border again disappears. Perhaps
this can help to track down the bug.

Comment 15

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

That's the bottom of the DIV. I'm not completely sure why the DIV's height is 
higher than the text field, but I think it's because the whitespace after the 
text field is wrapping onto a new line, so the DIV is two lines high.

Note that the DIV is 50% transparent and has a red background, so it renders 50% 
red/50% white. The textfield inherits 50% transparency, and has a white 
background, so it renders 50% white on top of what's already there, resulting in 
25% red/75% white.

Comment 16

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

I suspect the bugs you're seeing are to do with clipping of translucent content 
in nsViewManager2. nsViewManager2 just doesn't clip translucent views correctly 
at all, the results are very random. It basically picks the clip rect of the 
topmost translucent view that's being painted and uses that to clip ALL the 
translucent views. It was just never meant to work.

Comment 17

[bsharma]

Updating QA contact.

Comment 18

[bsharma]

Build: 2000092711 MN6
Platform: WinNT

The initial problem that "A semi-transparent textfield (on Windows) has a too
thin upper border when initially rendered. When the text inside is modified, the
textfield is re-rendered in a correct way" still exists but the application
doesnot crashes anytime.

Removing the crash keyword.

Comment 19

[Taras Tielkes]

The crash that I would see with this bug (can't remember which testcase) was on 
Linux. Unforutanely, I don't have a Linux workstation nearby right now to test 
this.

Comment 20

[Taras Tielkes]

I just tried this on WinNT, with a 2000-10-04-20 build, and one additional quirk
that I see is this:

In the 2nd and 3rd testcase, hold down a key to autorepeat-fill the textfield.
After 50 or so characters inserted/appended, the rest of the characters don't
render at all. Spaces or invisible characters are inserter/appended, it seems.

Comment 21

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

Stop worrying about this bug until the new view manager is checked in.

Comment 22

[Vladimir Ermakov]

QA Contact Update

Comment 23

[Taras Tielkes]

So, is the new view manager checked in? The testcases seem work fine.

Marking worksforme...

Comment 24

[Vladimir Ermakov]

Verifying