Closed Bug 172530 Opened 23 years ago Closed 22 years ago

url drop-down box appears to the left of the url bar

Categories

(Firefox :: Toolbars and Customization, defect)

Product:
Firefox
Component:
Toolbars and Customization
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Firebird0.7

People

(Reporter: hawks5999, Assigned: mconnor)

References

Details

Attachments

(4 files)

Autocomplete working right
95.59 KB, image/gif
Details
Autocomplete not working right
108.96 KB, image/gif
Details
Autocomplete not working right 2
106.21 KB, image/gif
Details
patch
1.25 KB, patch
deanis74
: review+
bryner
: superreview+
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021003 Phoenix/0.3 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021003 Phoenix/0.3 If you customize the toolbar to create a new toolbar and move the address field to that toolbar and the GO button is not to the immediate right of the address bar field, the autocomplete dropdown appears off the screen to the left. This happens if the GO button is completely removed from the toolbars as well. Reproducible: Always Steps to Reproduce: 1. Customize toolbar, add new toolbar (called address for example) 2. Move the address field/box to the new toolbar 3. Place the GO button anywhere except to the immediate right of the address field box. 4. Type in a URL that autocomplete would respond to. Actual Results: The autocomplete dropdown list appeared to the far left of the screen so that only the very right of the list could be seen. Expected Results: The autocomplete dropdown list should have been directly beneath the address box. I have configured the address bar as a separate toolbar to facilitate the transition away from IE where the address bar is separate from the navigation bar.
This is how autocomplete is expected to work
This is the error happening
This is a better view of the error
Wow, we release noted it and didn't have a bug. Thanks Douglas.
Status: UNCONFIRMED → NEW
Ever confirmed: true
It's not just autocomplete, its the url drop down box in general that is broken. It seems to happen for me when the window is "restored" to where you can drag it around. It is sporadic and happens with or without the "go".
Actually, I don't know if this is how it is "supposed" to be. It is reproducible every time if you put the window in restore mode then drag the browser slightly to the left or right off the screen then try to do the drop down box.
An easy way to reproduce this is by moving the address bar to the menu bar and then maximize the window. Now press the drop down arrow on the address bar. -> Toolbars
Severity: minor → normal
Component: Autocomplete → Toolbars
OS: Windows XP → All
This problem only seems to appear in screen resolutions greater than 800 by 600, but only when maximized. The drop-down menu appears in the correct spot in 800 x 600 even when maximized.
I see this all the time on my linux laptop 1600X1200 maximized.
Still there in 0.4 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3a) Gecko/20021114 Phoenix/0.4
I don't see this on RH8 builds from the last few days. I've added the addressfield to the menubar, maximized the window and I'm running at 1600x1200. I used to see this all the time but don't now. Are others still seeing this?
I still see this using the latest windows nightly (which is old, nov 19th). Running Windows XP.
Target Milestone: --- → Phoenix0.6
At least visually, this is very similar to bug 174176. Duplicates?
I don't see this anymore on Mozilla/5.0 (Windows NT 5.0; en-US; rv:1.3b) Gecko/20030227 Phoenix/0.5, but I'm still seeing bug 174176. Can anybody confirm this?
*** Bug 174176 has been marked as a duplicate of this bug. ***
Simon: No, but bug 172530 is actually a dupe of this bug, since it deals with the exact same problem (url drop-down bar to the far left of the screen). See comment 7 for a simple way of reproducing the bug (if you have a large screen resolution).
Summary: autocomplete in address field is off screen depending on position of GO button and address field → url drop-down box appears to the left of the url bar
Sorry, I ment that bug 174176 is a dupe of this bug. (Wrong bug number in Clipboard!)
*** Bug 196632 has been marked as a duplicate of this bug. ***
*** Bug 196875 has been marked as a duplicate of this bug. ***
Using the nightly build, Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030328 Phoenix/0.5, XP box, a 1024x768 desktop, maximized phoenix window, the dropdown box is still drawn half off the screen. A non-maximized window will not have this problem I have customized my menubar by dragging the Back, Stop buttons and addressbar into the main menubar (to the right of 'Help' menu) I first noticed this when I went from the Phoenix0.5 milestone to 3/3 nightly build. it's still in there as of 3/28 POSSIBLE FIX! adding something to the RIGHT of the addressbar will make the dropdown appear properly. Not just the Go button, it can be a seperator, Print, Home, etc, anything. So this seems like a "If addressbar is Right-most object on bar, then bug" bug
Target Milestone: Phoenix0.6 → Phoenix0.7
I just moved my address bar to the right of the window and it did not do it, but when I moved the window to the edge of the screen it started to show off to the left. I also noticed that if the menus are close to the left or right edge of screen that it does this, but only on wondows and it only moves the menu to the right 4 or 5 pixels from the left side of the screen when the menu is on the left side of the screen. Could it be the menu code causing this problem? I noticed that mozilla does the samething and that the XUL toolkit uses menus as the dropdown list also.
*** Bug 202948 has been marked as a duplicate of this bug. ***
*** Bug 206102 has been marked as a duplicate of this bug. ***
*** Bug 206140 has been marked as a duplicate of this bug. ***
Please fix!! It's a major bug for me!!!
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030516 Mozilla Firebird/0.6 WinXP 1024x768. Have the same problem but I confirm that when I added a separator after the address/location bar then it fixed the problem.
Has anyone moved the mozilla window so that the url bar is close to the right edge of the screen, I have the same thing happen in Mozilla when I do. This is a Mozilla bug too, so we need to look at the Mozilla code also. Do you also notice the problem with the left side of the screen, both menus and dropdowns are moved 4-5 pixels away from the left edge of the screen. It looks like the menu code is causing the problem with the dropdowns since they both have the same behavior.
*** Bug 206547 has been marked as a duplicate of this bug. ***
The same thing happens with the drop-down autocomplete in the Search field, under the same circumstances (Window maximized, nothing else to the right of the field) except that it only seems to happen for the search field if #search-container is used in userChrome.css to set a particular width. I'd guess that the problem is the same. Happens for me both on Windows 2000 and XP, multiple builds, including 20030519.
*** Bug 206941 has been marked as a duplicate of this bug. ***
*** Bug 207594 has been marked as a duplicate of this bug. ***
Ok, I'm not a good programmer, so I have no idea what silly code may be responsible for this behavior. This is the only real bug I've ever noticed on Phoenix or Firebird, so I've been thinking about it for quite some time. As I understand it, the toolbar "wants" something to the right of the address bar. If there isn't something there, then it screws up the auto-complete thing, and this bug happens. The temporary solution of mine has been to either leave the search bar there, or just put the "Go" button there, because it's smaller. The best solution I've found is to just put "nothing" on the right side to satisfy the toolbar's need for something over there. My (stupid) solution is as follows: 1) Right click the toolbar 2) Click Customize 3) Drag away any "Go" button or search bar or whatever else may be to the left of the address bar. 4) Drag a "Flexible Space" to the right of the address bar, where the "Go" button or search bar used to be. 5) Click "Done" The flexible space you just put there will collapse into nothing, so it looks like there is nothing to the right of the address bar, just like you want it. The crazy code that I don't understand will stil think there is something there (A flexible space), so it won't render the auto-complete list to the left of the screen. So, it's a solution. It doesn't deal with the rool cause of the problem, but it solves the symptom. Hopefully, some programmer out there can figure out WHY this is happening, but in the meantime, I think this is at least ok.
I am running: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030513 Mozilla Firebird/0.6 I am not seeing this problem anymore when the location bar touches both left and right sides of the screen. I still think this is a bug w/ Mozilla and we need to clean up the XUL code to correct it.
The easy way to reproduce the problem is to move the window in such a way that the dropdown would reach off the right edge of the screen. I can reproduce this without needing to maximize anything. This will occur *even if you have something to the right of the item*. Just move the window off the screen to the right until the drop-down would exceed the right edge, and boom. Simplified steps: 1) Create a new profile (so you get default configuration, window size, etc.) and launch firebird into this profile 2) Move the window until only half the urlbar is visible (the rest being out of the screen to the right) 3) Clear the urlbar and type "m" (mozilla.org would have loaded already, so it's in your autocomplete list) The drop-down will appear quite a bit to the left of directly under the urlbar. There is no need to customize anything. Oh, and I confirm this behavior on linux in the latest nightly (as of 5 hours ago) from mozilla.org.
Keywords: helpwanted
Whiteboard: fix or workaround patch needed
Using: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030614 Mozilla Firebird/0.6 Another way to reproduce is to start Firebird maximized at a small resolution (800x600). Then change to a larger resolution. Open the address bar or begin typing an address to start autocomplete, and it will appear off the left-side of the screen. It seems that Firebird doesn't recognize the change in resolution. When the drop down does appear on screen it is the same size as when using the small resolution.
*** Bug 209564 has been marked as a duplicate of this bug. ***
*** Bug 210005 has been marked as a duplicate of this bug. ***
Can reproduce this pushing the dropdown to either direction depending on which way I move the URL bar off the screen. It looks like something in the code governing the dropdown tries to prevent the dropdown from being drawn off the screen. There are two bugs with wherever this is implemented. 1) when the URL bar goes offscreen to the right, the right edge of the dropdown aligns with the left edge of the bar, instead of pushing left just far enough to stay completely on screen (as it does when you push offscreen to the left) 2) if the URL bar is the right-most element in the toolbar, the code that detects whether the dropdown will render completely onscreen incorrectly interprets the right edge as being offscreen, forcing the buggy realignment. This is why the flexible space workaround will work. However, autocomplete dropdowns in web forms will still misalign if they get within the edge area. it really happens anywhere there is a dropdown, with the same misaligning effect if it hits the right edge of the desktop area (at least on win2k). I'm going to try to track this one down this weekend now that I think I have some idea of what I'm looking at.
Yes, there's definitely menu code that does all that's described here, like flipping it on its vertical axis. It's in nsMenuPopupFrame::SyncViewWithFrame(), specifically the check to IsMoreRoomOnOtherSideOfParent(). The reason that putting something like a spacer to the right of the address field "fixes" this behavior is because the repositioning is done if the menu is within 5 pixels of the screen's edge ("// inset the screen by 5px so that menus don't butt up against the side"). Is the auto-complete widget just an editable combo box, or is it actually an edit box and an attached menu? If the former, then we'd see the same problem in the wallet dialog in Moz. If the latter, this is going to be tough to fix because we need this behavior for menus.
My C++ knowledge is relatively limited, however this is the part I was looking at before: http://lxr.mozilla.org/seamonkey/source/layout/xul/base/src/nsMenuPopupFrame.cpp#1252 Near as I can make out, under SeaMonkey the URL history is anchored to the URL bar. However, under Firebird its not, which is how it gets to this point in the function. So either the URL history and autocomplete elements need to be anchored or we need to modify the "if (tag == nsXULAtoms::tooltip)" check to include those elements as well to make them reposition properly. (Does that constitute a cheap hack?) I don't think that IsMoreRoomOnOtherSideOfParent() is the issue here, that works with the bookmarks menus, but if you shrink the window to fit on one half of the screen, it still stays positioned unless you go offscreen.
Still a problem with 20030714. Appears to happen also when the address bar is moved slightly off the screen to the right. A fix for this would be greatly appreciated.
*** Bug 213202 has been marked as a duplicate of this bug. ***
Taking QA Contact
QA Contact: asa → bugzilla
Why don't we remove the 5 pixel buffer on the edge of the screen? "// inset the screen by 5px so that menus don't butt up against the side" <-- lets remove this and see if the problem is fixed, besides all other Windows apps let the menus and drop downs touch the edge. I think it is worth a try and then we can work on fixing the changing resolution problem that is also a part of this bug. I still think that we need to try and split the menu and dropdown code or add a flag to the current code to switch between the two. This a a major problem in Mozilla Firebird and Mozilla, people will see this as a defect in the code and they will think all of the code is defective.
the current implementation is fine, if it works the way it works in Mozilla, which nudges the dropdown just enough to stay on screen. since this is Hewitt's bug and he's not working on Firebird, taking to evaluate/fix once my build environment is working
Assignee: hewitt → mconnor
Attached patch patch — — Splinter Review
I can't figure out why we'd ever want to move a popup that isn't anchoredToParent over the full width of the popup, the method for tooltips (figure out how far offscreen it is, move it over that far) makes far more sense, and if the popup is wider than half the screen, we're quite possibly going offscreen to the left (as seen here with the URL bar)
Comment on attachment 128886 [details] [diff] [review] patch requesting review from module owner (bryner). I believe I'll need an sr as well on this as well at some point.
Attachment #128886 - Flags: review?(bryner)
Comment on attachment 128886 [details] [diff] [review] patch I'm going to ask Dean to review this since he was the last one in this code. Dean, was there a reason for handling tooltips differently, or was it just to reduce the risk since the bug you were fixing only affected tooltips?
Attachment #128886 - Flags: review?(bryner) → review?(dean_tessman)
Status: NEW → ASSIGNED
Yes, it was because we were specifically fixing the positioning of tooltips that extended off-screen. I didn't write the code, but I did review it. Looking at bug 73970 comment 31 through to comment 34, I think it is an unnecessary check. Before I review, what's making this anchored in Mozilla but not in Firebird?
Dean, the autocomplete in FB specifies starting point via XY coords, which means it doesn't end up as anchoredToParent and then hits this code, however when I looked at this before, the autocomplete in Moz is positioned based on the parent position, so it follows the other branch of the function. I don't know of anything else in the UI that uses this code. I've been running with this change in my tree since yesterday and have not experienced any problems. Oh and because I know you'll notice it, the line that's left, that was in the if statement, should be moved left two spaces to be formatted "correctly" I noticed after I entered the review request and figured a trivial formatting glitch wasn't worth a bunch of bugspam to change. :)
Comment on attachment 128886 [details] [diff] [review] patch Thanks for the clarification, and for spoiling my nit about the spacing. r=me
Attachment #128886 - Flags: review?(dean_tessman) → review+
Comment on attachment 128886 [details] [diff] [review] patch sr=bryner
Attachment #128886 - Flags: superreview+
Fix checked in. Should be in today's builds, if not, tomorrow's.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Keywords: helpwanted
Resolution: --- → FIXED
Whiteboard: fix or workaround patch needed
*** Bug 214789 has been marked as a duplicate of this bug. ***
Verified fixed with 20030803 build on W2K. Thanks Mike.
Status: RESOLVED → VERIFIED
*** Bug 215101 has been marked as a duplicate of this bug. ***
*** Bug 215233 has been marked as a duplicate of this bug. ***
*** Bug 215486 has been marked as a duplicate of this bug. ***
*** Bug 217482 has been marked as a duplicate of this bug. ***
*** Bug 217720 has been marked as a duplicate of this bug. ***
this problem is fixed for me when aol instant messenger is docked
*** Bug 218865 has been marked as a duplicate of this bug. ***
QA Contact: bugzilla → toolbars
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: