This is a regression in today's build (2001-06-27). If you click the drop-down button to the right of the URL bar, it goes bat shit. The URL centers itself; if the URL bar was empty, it balloons out to a 150px tall empty hole.

in the trunk or the branch? This seems like a layout issue.. there haven't been many urlbar changes in the last few days, especially ones might even closely relate to this..

trunk-only.

->URL Bar component.

P3 for now as it is not on the branch.

Just some notes on that attached screenshot. 1) I'm pretty sure this is the same problem being described, but I could be wrong. 2) Screenshot is on a W2K SP2 box, Build ID: 2001070108

Marking all/all Happens on linux too, trunk of the 30th Screenshot in linux: http://vivaldi.ing.ula.ve/~fricardo/mozilla/historia.jpg

this is some wierd editor issue.. nothing has changed with the urlbar in ages...

seems like xpfe issue not editor

hot potato, hot potato... luckily this whole url bar widget/dropdown-thing is hewitt's baby!

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

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

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

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

I've noticed this in the builds from the past couple of days, around the same time I started noticing changes to the Modern theme. I also see this with the Classic theme, though.

I think this one is becoming really annoying and will more than likely cause quite a few more dupes to be filed.

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

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

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

I noticed that if you hide the navigation toolbar (really hide, with View->Show/Hide->Navigation Toolbar) and them you make it visible, the url bar size and text alingment and also its behaviour become normal.

Strange that this did not happen in 2001062914 build for Mac, though this bug is filed on 0627. In Mac , it started in 0703 builds.

marking mostfreq preemptively. qawanted: can someone try to pinpoint exactly when we regressed (down to a day, down to an hour, down to a checkin)

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

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

Summary change suggestion: from: 'URL bar freaks out if you click on drop-down icon' to: 'URL Bar resizes permanently when clicking on its drop down button'

I have tested nightly builds to find the time this regressed on linux. The following builds do not show this problem: 2001062906 and 2001062909-gcc2.95. The build 2001062921 exhibits this bug. Just to confirm: I do mean the problem did not appear until the 29th June on Linux. Further details (probably irrelevant): I am running LinuxFromScratch compiled using gcc2.95 running kernel 2.4.4 and XFree86 4.0.3. My methodology was to download each of the nightlies; unpack them in their own directory; delete my .mozilla directory; run the build; visit www.slashdot.org and www.freshmeat.net by typing in the location bar; finally click on drop down history button.

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

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

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

This seems to have happened at the same time as another URL bar change appeared. Previously, one double-clicked on the URL bar to mark the entire text, now a single click does it.

this just showed up on the branch on all platforms as of 07/06

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

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

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

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

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

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

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

This regression was caused by the patch for bug 84645. Backing that patch out in my tree fixed the problem.

Should we back that out, then, since this is a much more visible, and annoying, bug?

PDT+ We should understand the interaction here and then choose our course. Does anyone know what the relationship is?

Please check in bug 89568 what actions activate and deactivate the bug, perhaps this would lead to somewhere

From what I can gather... The overflow (resize or expansion) is causing a resize in the parent (navbar). Before the patch for bug 84645 went in, it didn't try to call the parent. I'm looking a little closer to see what I can see. (Override for navbar anyone?) Does the drop down need to be a separate layer than the parent? I'm thinking aloud here.

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

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

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

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

Would it be appropriate to call this a "priority" P1 or P2 bug? I suggest to back out the bug 84645 fix pronto!!! It is FAR less important than the DAMAGE this bug is doing. Then TEST the other bug fix until you know it wouln't do this again. Only then resubmit the fix for bug 84645. I have never seen a bug grow as *quickly* as this one (votes, CC's, duplicates).

I agree. This very noticeable regression has been around for 11 days now. The usual practice in the past has been to back out the regression-causing checkin and then diagnose it locally. Why is it different for this?

It think this bug make Moz very unstable because IF I produce it I always receive an System error type 11 (under MacOS 8.6) after few minutes... and menus become mess up sometime...

I noticed that after the bar enlarges to about 150px, the View/Show-Hide/Navigation Toolbar menu doesn't work anymore. hth, win95 2001070808

You can do File -> New Navigator Window as a workaround and close the problem window. Also, if you clear the URL bar (View -> Preferences -> Navigator -> History -> Clear Location Bar), then when you hit the arrow the URL shifts to the right rather than the bar taking lots of vertical space.

So how about we back out the changes from bug 84645 on the branch, and reassign the bug to me to fix on the trunk?

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

Chris, if you can fix it in the next day or two on the trunk, then sure. Otherwise I'd rather it was backed out of both the trunk and the branch. I'm getting tired of marking bugs as duplicates! How serious was the problem that bug 84865 fixed? From what I can tell, it was a fringe case that almost never happened. If we can't fix this regression quickly it makes more sense to me to get rid of the regression. I've had much less noticeable regressions than this backed out in a matter of hours. This one's been around for a lot longer than that.

<QA_ignore> 25 dups, 30 votes, nasty comments on the newsgroups. Let's back this up ASAP. </QA_ignore>

All yours, baby.

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

So the problem with the patch is that you don't want to grovel around for a new parent unless your parent is splittable, which box frames aren't. (That is, a box frame will never have a continuation.) This fixes the box frame to not lie about its ability to be split, and checks the split-type in the frame ctor to avoid grovelling for unsplittable frames.

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

So what you're saying is that it fixes it without backing out the fix for bug 84865 ? If so .. perfect ! :)

The patch makes sense, although it's out of my domain to give an r= to. Can the "if (NS_FRAME_IS_SPLITTABLE(splitType))" check be moved up higher, above "if (prevSibling)"? We should drop straight to the "else" if the frame isn't splittable, shouldn't we? Are there any other classes that are going to bite us because they're not splittable? Should we add IsSplittable to anything else right now?

hyatt sez [s]r=hyatt.

dean: we don't want to drop into the |else| clause unless |!prevSibling && !nextSibling|.

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

Changes backed out on the branch.

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

branch builds are fixed...still present on trunk builds

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

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

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

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

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

Okay, dbaron is _such_ a bully! He made me sit down and figure out why |ContentRemoved()| was making the URL bar freak out. And he took my lunch money. Waah! Here's the situation. When the URL bar is clicked, We get an |AttributeChanged()| which causes a |RecreateFramesForContent()|. The node that we want to recreate frames for is a <menupopup>. |RecreateFramesForContent()| first calls |ContentRemoved()|, which ends up being a no-op because the <menupopup> was |display: none| up until this point. That is, there is no frame to remove. Then we call |ContentInserted()|, giving the parent container as the <menu>, the child conten as the <menupopup>, and the index to insert as 1. At this point, it's useful to know that the content model looks something like this: <menu> <image /> <menupopup>...</menupopup> </menu> And the frame model looks something like: nsMenuFrame(<menu>)< nsBoxFrame(1)< nsBoxFrame(2)< nsImageBoxFrame(<image>)< > > (...more nsBoxFrames...) > nsPopupSetFrame< (!!!) > > (As an aside, I don't know where the nsPopupSetFrame comes from: it appears to be part of a content model that looks like: <hbox> <hbox> <textbox> <popupset /> </textbox></hbox></hbox> How its frame ended up as a child of the <menu> is a mystery to me!) So, |ContentInserted()| finds the |nsMenuFrame| as the |parentFrame|. It calls |FindPreviousSibling()| on the <menu>, and using |nsIContent::ChildAt(0)|, discovers that the <image> frame is the apparent ``previous sibling'' of the new frame we're about to create and insert. This is where things start to go wrong. Next, the code that I put in for bug 84645 kicks in. Since |prevSibling| is set, it attempts to fix up the |parentFrame| pointer (as if it was dealing with a continued HTML frame). It alters |parentFrame| to point to |prevSibling|'s parent, which is nsBoxFrame(2), above! The frame insertion code now tries to insert the frames created for the <menupopup> beneath nsBoxFrame(2) instead of beneath nsMenuFrame, and all hell breaks loose. So why does this work with the above patches, since |prevSibling| has been corrupted already? It turns out that none of the menu construction code actually _cares_ about |prevSibling|, so everything comes out in the wash. Now that I've done this analysis, I'm less convinced that my patch is correct.

...so I'll back my changes for bug 84645 out as soon as the tree opens, and then try to work out a proper fix.

Okay, I've backed out changes in r1.603 to nsCSSFrameConstructor.cpp; bug 84645 has already been re-opened, so I'll try to come up with a better fix over there.

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

WFM with fresh CVS Win32 build(WindowsME). Asa would probably frag me if I verified/fixed this without Mac & Linux WFMs, so feel free to comment on that.

So nice to be able to view my URL bar drop down history again! WFM on Linux 2001071021 (trunk).

WFM linux x86 2001-07-10-21

Now fixed for me, Solaris SPARC CVS pull 2001/07/10-23:00 ADT.

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

Seems like a major rendering speed improvement after this was backed out on the nightly build. In remembering back, it seemed a lot faster before the fix went in. I could be wrong.

Verifying. Thanks for backing those changes out, Chris.

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

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

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

Please reopen. It's Win32 Nightly (build 2001071604) Now it thinks it's parent constraint is the size of my desktop... Attaching screenshot...

Hmm i had that same case a long time ago. What happens if you click on the drop down icon again?

tswan: That is another bug. See bug 83944.

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