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

RESOLVED WORKSFORME

Status

Core Graveyard
GFX: Win32
RESOLVED WORKSFORME
15 years ago
10 years ago

People

(Reporter: Jelle Raaijmakers, Assigned: Kevin McCluskey (gone))

Tracking

Trunk
x86
Windows XP

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

15 years ago
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.

-
Sounds like a win32 gfx issue (no problem on Linux).
Assignee: font → kmcclusk
Component: Layout: Fonts and Text → GFX: Win32

Comment 2

15 years ago
yeah... WFM OS X 1.4b

Comment 3

15 years ago
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?
(Reporter)

Comment 4

15 years ago
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

15 years ago
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.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → WORKSFORME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.