264711 - transparency example freezes window management controls

Status: RESOLVED FIXED

(Core :: XUL, defect)

Description

[Nigel McFarlane]

The purple octopus example of bug 113232 damages the
mozilla window under Win98.

If the window is displayed using (eg Firefox PR1)
firefox -chrome "file://c:/tmp/test99.xul", then:

1. the window is always placed at (0,0) on the desktop
2. the titlebar, although visible, is completely unuseable
3. if the window loses focus, then the titlebar is greyed
   and does not recover its former colour when focus is
   returned

The user cannot, therefore, move, close or minimise the
window with the mouse. Alt+F4 still closes; Alt+Tab still
sends the window behind another and brings it back.

Comment 1

[Dainis Jonitis]

Mozilla Firefox PR1 does not have support for translucent windows (bug 252067).
Only Mozilla Suite 1.8a3 and newer builds have this feature.

And I do not think we should care too much about anything older than Win2000.
Although it is possible to create non rectangular windows with complex shaped
regions it will still be just a 1-bit transparency mask.

Comment 2

[Nigel McFarlane]

Confirmed with an Oct 27 trunk build. Is that recent enough?

I think win98 is still an official port. It's certainly a large
population of users - bigger than the Mac or Linux.

I think 1-bit transparency masks is bug 264708. There it's
requested as an enhancement. 1-bit is better than 0 bits.

- N.

Comment 3

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

Dainis, then shouldn't transparent windows be completely disabled on Win98 so at
least you get a working window, even if it's not transparent? Actually I thought
they already were...

Comment 4

[Dainis Jonitis]

If I understood right then Nigel seen this problem with _Firefox_.
But Firefox is on a branch which did not include my changes for bug 252067.

The fact that titlebar is visible must mean that there is a bug in _Firefox
branch_ nsWindow::HideWindowChrome function.

Even with Mozilla 1.8a3 the window should not be moveable, because for
translucent windows WS_SYSMENU, WS_MAXIMIZEBOX, WS_MINIMIZEBOX are intentionally
cleared.
That's:
  https://bugzilla.mozilla.org/show_bug.cgi?id=252067#c49

I'll look at the source code of Firefox to understand how much it differs from
trunk. I'll also verify Mozilla 1.8 trunk on Win98 to see these problems myself.

Comment 5

[Nigel McFarlane]

Dainis, the trunk nightly I tested isn't Firefox, it's MAS.
 
Is my ignorance is showing? Is there a reason why normal
window management ops with the mouse are disabled?  Is there
a reason why the new window shouldn't obey the stacking and
offset positioning rules that new windows generally obey?

The only difference I saw between last night's trunk and
Firefox PR1 is this:

The trunk doesn't acquire a titlebar when the window is
first created, but firefox does. If you cycle through the windows,
then the trunk version _acquires_ a titlebar when it's put back
on top. After that, they're the same. HTH.

- N.

Comment 6

[Nigel McFarlane]

Tested on MAS 1.7 Gecko/20040616. Same problem, no titlebar
on first window display, titlebar appears subsequently.

It's not a very recent code regression, then. It's an older bug
revealed by the new test data.

- N.

Comment 7

[Nigel McFarlane]

Duplicated with MAS 1.4. You get a titlebar straight away this time.

We need one more person to test to get parallax. It's Windows.

- N.

Comment 8

[Nigel McFarlane]

Fixed by fix for bug 264708. Confirmed with 2004-12-10 nightly trunk.
See bug 274150 for HTML case.

- N