204865 - selected text on layer is rendered incorrectly while partially covered by IFRAME

Status: RESOLVED WORKSFORME

(Core Graveyard :: GFX: Win32, defect)

Description

[Jelle Raaijmakers]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3.1) Gecko/20030425
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3.1) Gecko/20030425

Some fonts in layers that exist above IFRAMEs become bold and change to the font
'System' when selected. On the above URL you can see this behaviour I've
experienced with Mozilla 1.3.0 and 1.3.1. When I remove the IFRAME, it seems to
work again. I believe it only happens when the layer has an opacity value. In
the testcase I used .75 or 75%.

I've experienced more problems with the IFRAME element in Mozilla, such as black
flickering when resizing and such. Maybe this element hasn't been implemented
correct yet?

Maybe it seems like a strange construction, but I used an IFRAME to display the
documents and transparent menu's (layers) above this IFRAME.

Reproducible: Always

Steps to Reproduce:
Not sure about the reproduction steps, but this seems to work:

1. Create a layer with some text
2. Create an IFRAME with offset 100, 100, src about:blank
3. Select the text
Actual Results:  
When selected, the font changes and doesn't change back.

Expected Results:  
It should have displayed the normal font and font-weight.

-

Comment 1

[Boris Zbarsky [:bzbarsky]]

Sounds like a win32 gfx issue (no problem on Linux).

Comment 2

[Chris Casciano]

yeah... WFM OS X 1.4b

Comment 3

[Marco Perez [:mpk]]

I could reproduce this with an older Phoenix build (ID: 20030405). WFM on a
newer Mozilla build (ID: 2003042608). Maybe this got fixed on the trunk after
the 1.3 branch. Reporter, can you reproduce it with a recent nightly build?

Comment 4

[Jelle Raaijmakers]

I have opened the testcase with the latest nightly build (5/8 - 5/9) and it
seems to be fixed. Does anyone know why it hasn't been backfixed into the 1.3
branch?

Comment 5

[Marco Perez [:mpk]]

The bug seems to be fixed on the trunk, so since the upcoming 1.4 release will
mark the beginning of a new stable branch, I resolve this as "worksforme". If
someone thinks the fix should be ported back to the older branches branch(es),
feel free to reopen this bug. I have a simplified testcase ready, should this
happen.