33617 - locking window size with enlightenment also locks all subwindows

Status: RESOLVED DUPLICATE of bug 29856

(Core :: XUL, defect, P3)

Description

[John Ellson]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; N; Linux 2.3.99-pre3 i686; en-US; m14)
BuildID:    2000032309

Using the Enlightenment feature that remembers the size of a window between
sessions has the effect of locking the size of all Mozilla subwindows to the
same value.  Subwindows (e.g. preferences or Mail) should keep their original
default sizes.  Netscape 4.72 does this right.  e.g. you can remember separate
size and position for browser and mail windows.

Reproducible: Always
Steps to Reproduce:
1.Linux + Enlightenment WM
2.Size mozilla to full screen, configure e to remember size
3.Open subwindow (e.g. preferences or mail)


Actual Results:  Subwindow takes size of main window

Expected Results:  Subwindow should keep its own default unless new size has
been "remembered" in e explicitly for that subwindow.


enlightemnet dr16

Comment 1

[Asa Dotzler [:asa]]

[e-mail] (Asa Dotzler) taking ownership of Browser General bugs. 
 New QA Contact is [e-mail] (Joseph Elwell).  Sorry for the spam.

Comment 2

[Asa Dotzler [:asa]]

Confirming,updating component and owner.

Comment 3

[John Morrison]

I know you say enlightenment, but is this referring to gnome session management?
What are the steps to "configure e to remember size" -- the enlightenment
configuration tool that I have does not present that option. Sairuh -- can 
you answer this?

Comment 4

[Peter Trudelle]

moving to m30, helpwanted

Comment 5

[sairuh (rarely reading bugmail)]

actually haven't tried this before in enlightenment, h'm. [i've been having
adventures where enlightenment keeps running over afterstep --weird that i keep
getting 2 wm's running at the same time, erk.]

Comment 6

[Peter Trudelle]

Mass-moving all M20-M30 XPToolkit bugs to Future

Comment 7

[Decklin Foster]

I believe what E is looking at is the WM class atom. Here's a comparison of 4.x
and moz:

WM_CLASS(STRING) = "mozilla-bin", "Mozilla-bin" (same for all)
WM_CLASS(STRING) = "Navigator", "Netscape" (different for browser vs. mail etc)

I think there's a bug somewhere on using different icons for the different
window types... looks like another part of the same issue.

Comment 8

[Asa Dotzler [:asa]]

*** Bug 61206 has been marked as a duplicate of this bug. ***

Comment 9

[Peter Trudelle]

->danm/untargetted.   Is this a toolkit or an XPApps issue?  They appear to have
fielded bug 57576, which seems related.  Also, is there/should there be a
separate bug to have a separate WM_CLASS(string) values for each "application"?
 That sounds like an accessibility issue, since screen readers need to
distinguish window types by a speakable string.

Comment 10

[Dan M]

Is this a duplicate or side effect of bug 29856?

Comment 11

[R.K.Aa.]

looks like a duplicate. Resolving as such.

*** This bug has been marked as a duplicate of 29856 ***