[modern3] after theme change (only) URL bar and search button alignment wrong

RESOLVED WORKSFORME

Status

Core Graveyard
Skinability
P3
normal
RESOLVED WORKSFORME
17 years ago
10 years ago

People

(Reporter: Jesse Michael, Unassigned)

Tracking

({helpwanted, regression})

Trunk
mozilla1.0.1
x86
All
helpwanted, regression

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(4 attachments)

(Reporter)

Description

17 years ago
In the modern3 chrome, the url bar and the search button are offset vertically
from where they should be.
(Reporter)

Comment 1

17 years ago
Created attachment 32857 [details]
Screenshot of misalignment
What build are you using?  worksforme, build 2001-05-01-08
(Reporter)

Comment 3

17 years ago
okay, a little more info.  it showed up like this when i switched from classic
to modern, but after i quit and restarted mozilla it looked okay.
(Reporter)

Comment 4

17 years ago
built from cvs checkout earlier today (may 1, 2001) around noon pst

Comment 5

17 years ago
I concur, When switching to Modern3 theme from a different theme (classic for
example,) the browser allignments (buttons, url fields) are out of place. This
seems only to be happening on just the browser as Mail/News, composer, and
contacts seems to be unaffected when trying to allign button. (They allign up
where they suppose to be as if you started moz up with modern3)

I also noticed that filling out forms (like the Additional Comments: form) with
one theme, then switching to another, does not have the text you typed prefilled
in. It is only when you switch back to the theme you origionally started filling
the form in that you see that text you typed. Should I file this as another bug?
This bug and bug 78688 seems to be the same. That bug was marked as duplicate 
of bug 78221, so I suppose this bug is also a dup of bug 78221.

Also look at attachment 32874 [details] on bug 78221

Comment 7

17 years ago
so should this be a dup of bug 78221 ?
No, that bug is for all the useless spam. This is a valid bug.. setting status
to new. Possibly layout, though....
Status: UNCONFIRMED → NEW
Ever confirmed: true
This is a dup of bug 78221

Please someone mark as fixed/duplicate
No!  This is _not_ a dup of bug 78221.  78221 is for _design_ suggestions on
modern3. This is not a design suggestion -- that part is designed already.  This
is an implementation bug with something not specifying its size correctly
causing a weird reflow.
Boris,

Modern3 was included in the builds before it was finished. So, it has some
misalignment and problems ( See attachment 32874 [details] ). All the bugs about defects
and misalignments in modern3 should be duped to Bug 78221. That bug is not about
"design suggestions". The suggestions are discussed in the newsgroup or IRC.

If you don't believe me, then at least this bug is a dup of bug 78688

Here is the description of bug 78221. Please read (especially the "buttons out
of place" part).

--------------

I just landed the new design for the new Modern theme.  You will immediately
notice that many parts of the app look really bad - mismatching colors, buttons
that look out of place, etc... this is because the theme is a work in progress.
We have been asked to check it in now, and complete the design in public rather
than designing it in private and landing it all at once.

So, this bug is basically for duping the inevitable stream of "XXX looks ugly in
the Modern theme" bugs.

Daniel,

This bug is about a part of modern3 that's completely correct _until_ a theme
change.  This part of the design is afaik supposed to be done.  The fact that it
messes up after a theme change indicates an underlying bug in the CSS, most
likely.  This is not a design issue but rather an implementation issue.

I agree that this is identical to bug 78688 and I disagree with the resolution
of 78688.
Summary: URL bar and search button alignment wrong in Modern3 → [modern3] after theme change (only) URL bar and search button alignment wrong

Comment 13

17 years ago
During the tear-down and re-creation of the XBL for the urlbar binding,
something's going wrong here.  Reassigning to skinability
Assignee: hewitt → ben
Component: Themes → Skinability
QA Contact: pmac → blakeross

Comment 14

17 years ago
I see this on 2001051720 on WinMe (whoo!).  OS is probably ALL.

Updated

17 years ago
QA Contact: blakeross → pmac

Comment 15

17 years ago
*** Bug 82504 has been marked as a duplicate of this bug. ***

Comment 16

17 years ago
*** Bug 82581 has been marked as a duplicate of this bug. ***

Comment 17

17 years ago
Man...  It's gonna be the mostfreq if this ugly bug doesn't got fixed...  I
swear there would be dozen more dupe coming right here after 0.9.1 release...

Does it happen on Mac?

Comment 18

17 years ago
*** Bug 82985 has been marked as a duplicate of this bug. ***

Comment 19

17 years ago
OS/All per comments, plus keywords.
Keywords: mozilla0.9.2, regression
OS: Linux → All

Comment 20

17 years ago
*** Bug 83372 has been marked as a duplicate of this bug. ***
nav triage: Ben is pretty heavily loaded for mozilla0.9.2 and mozilla0.9.3,
we'll have to find someone else to look at this bug. As it does not sounds
critical enough, moving to mozilla1.0 for now. 
Keywords: nsbeta1-
Priority: -- → P3
Target Milestone: --- → mozilla1.0

Comment 22

17 years ago
*** Bug 83913 has been marked as a duplicate of this bug. ***

Comment 23

17 years ago
Some more details.
Only the windows open when I switch themes display this behavior. If I open a
new window, the URL bar is okay.

This appears to be related to bug 83370 ( "Open Link in new window" stops
working after theme switch), since newly created windows do not have any of the
two problems.

I'm using 2001060508 right now.

Comment 24

17 years ago
*** Bug 84619 has been marked as a duplicate of this bug. ***
This seems just like the incremental reflow bugs that are so familiar to people
who work on block layout, but which XUL avoids since it normally doesn't reflow
(I think) until the whole page is loaded.

Comment 26

17 years ago
*** Bug 84783 has been marked as a duplicate of this bug. ***

Comment 27

17 years ago
if you watch the skin repaint on a really slow machine (or a heavily loaded one)
you'll swear it *is* incrementally reflowing during the change, at least parts
of the skin, as they move around durring the rendering. Today i had the
"opportunity" to install Moz on a 266 Mhz Pentium 2 while it was busily cranking
on a large application in the background... I would never have noticed this,
except the user asked why it didn't look "cool high-techy like the one you run".
In the span of about two minutes while the skin applied itself, the various
components of the skin resize and reflow themselves in sequence. The bit in
question is initially very short, and the bottom *appears* to be correctly
located, then when it grows to normal height instead of growing up, it grows down.

Comment 28

17 years ago
*** Bug 84954 has been marked as a duplicate of this bug. ***

Comment 29

17 years ago
*** Bug 85063 has been marked as a duplicate of this bug. ***
Chris Abbey: That's (probably) not incremental reflow, it is in fact (probably)
just the images popping in and thus their frames changing their intrinsic size.
Incremental Reflow in this case means reflowing only _part_ of the chrome. You
can tell that this is not happening because while all the moving about is 
occuring, objects that are at the bottom of the chrome, e.g. the status bar,
appear there at the start of the movements, not during the movements.

Comment 31

17 years ago
Created attachment 38022 [details]
screen capture montage showing (incremental?) skin reflow

Comment 32

17 years ago
Ian, true the *whole* skin isn't reflowing, but I think the montage I just
attached shows that at least part of it, coincidentally the part we're talking
about herein, is. Perhaps it's not a reflow in the traditional document sense,
but  I think we'd agree that portions of the skin are being relocated as a
result of other portions being rendered.

I'm still looking for the uninitialized variable theory I put forward in my
initial bug 83913, but haven't found it. In looking at these shots, I don't
think this relocation is to blame, as miss-alligned url bar seems to move down
with the rest of the objects. What gave me the un-re-itialized variable idea is
that as the url bar re-renders itself it's first size (realy thin) is bottom
alligned with where the OLD url bar was, then when it resizes the top line is
the one that stays fixed and the bar render's itself relative to that. (if I'm
not being clear with that I can cut together a small comparison image.)

Comment 33

17 years ago
Created attachment 38025 [details]
what I was trying to explain

Comment 34

17 years ago
*** Bug 85394 has been marked as a duplicate of this bug. ***

Comment 35

17 years ago
10 dups, mostfreq.
Keywords: mostfreq, rtm

Comment 36

17 years ago
Just a note since I didn't see it mentioned: you do not need to reload to fix
the problem, you just need to open a new window.. the originating window will
still be broken, but not the new window.

Comment 37

17 years ago
*** Bug 78328 has been marked as a duplicate of this bug. ***

Comment 38

17 years ago
*** Bug 85750 has been marked as a duplicate of this bug. ***

Comment 39

17 years ago
Created attachment 38401 [details]
Netscape 6.1PR1 Modern3->Classic->Modern3

Comment 40

17 years ago
The image shows that the Modern3 transition is keeping some of the Classic's
attributes, most noticibly the Netscape-added button and the bookmark icons. 
This may help determine what Modern3 is doing wrong.  (of course it doesn't help
that half the time the theme doesn't even switch in 6.1PR1.)

Comment 41

17 years ago
*** Bug 86631 has been marked as a duplicate of this bug. ***

Updated

17 years ago
Blocks: 88358

Comment 42

17 years ago
Well, this bug is all but fixed as to change a theme requires you shut down and 
relaunch mozilla now.  Only bit of a boffo on that is that if -turbo is active 
the theme won't change simply by closing the window or openning a new one, you 
have to File -> Exit   which is kind of annoying, minorly.

My only remaining question is: did the latest/final modern3 updates to the 
chrome a couple days ago (06/28/2001 02:15) take care of the underlying problem 
tho?  Hewitt?
Mass move skinability bugs to nobody@mozilla.org, helpwanted. 
Assignee: ben → nobody
Keywords: helpwanted

Comment 44

17 years ago
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)
Target Milestone: mozilla1.0 → mozilla1.0.1

Comment 45

17 years ago
Using Linux 2002011508 this is no longer a problem.  Theme switching has been
redone recently.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME
(Assignee)

Updated

10 years ago
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.