38.06 KB, image/png
87.13 KB, image/png
3.34 KB, image/png
28.37 KB, image/png
In the modern3 chrome, the url bar and the search button are offset vertically from where they should be.
What build are you using? worksforme, build 2001-05-01-08
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.
built from cvs checkout earlier today (may 1, 2001) around noon pst
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?
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
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
I see this on 2001051720 on WinMe (whoo!). OS is probably ALL.
*** Bug 82504 has been marked as a duplicate of this bug. ***
*** Bug 82581 has been marked as a duplicate of this bug. ***
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?
*** Bug 82985 has been marked as a duplicate of this bug. ***
OS/All per comments, plus keywords.
Keywords: mozilla0.9.2, regression
OS: Linux → All
*** 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.
Priority: -- → P3
Target Milestone: --- → mozilla1.0
*** Bug 83913 has been marked as a duplicate of this bug. ***
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.
*** 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.
*** Bug 84783 has been marked as a duplicate of this bug. ***
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.
*** Bug 84954 has been marked as a duplicate of this bug. ***
*** 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.
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.)
*** Bug 85394 has been marked as a duplicate of this bug. ***
10 dups, mostfreq.
Keywords: mostfreq, rtm
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.
*** Bug 78328 has been marked as a duplicate of this bug. ***
*** Bug 85750 has been marked as a duplicate of this bug. ***
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.)
*** Bug 86631 has been marked as a duplicate of this bug. ***
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 firstname.lastname@example.org, helpwanted.
Assignee: ben → nobody
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
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
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.