Closed Bug 437822 Opened 18 years ago Closed 17 years ago

Edit bookmark in Bookmark Contextual Dialog displays extra box within name field for Microsummeries enabled websites

Categories

(Toolkit :: UI Widgets, defect, P3)

All
macOS
defect

Tracking

()

VERIFIED FIXED
mozilla1.9.2a1

People

(Reporter: whimboo, Unassigned)

References

()

Details

(Keywords: regression, verified1.9.1, Whiteboard: [fixed by bug 469631])

Attachments

(2 files)

Attached image Broken name field
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9pre) Gecko/2008060704 Minefield/3.0pre ID:2008060704 If you save a website which offers a live bookmark and edit this bookmark by clicking again on the star or pressing Cmd+D the name field looks broken. See the attached screenshot. Steps: 1. Bookmark the following page by pressing Cmd+D 2. See the broken name field The inner box shouldn't be visible.
Frankly, this baffles me. And I've noticed that it doesn't happen on Linux. What (do you think) is it about this bug's URL's title that triggers the problem -- its length? the fact that in contains Kanji?
No, it shouldn't be based on that parts. I found a page (made by Myk) with a list of Microsummeries enabled websites. All of them are showing this behavior. Looks like it's a general issue with Microsummaries. http://wiki.mozilla.org/Microsummaries/Sites
Summary: Edit Live bookmark in Bookmark Contextual Dialog displays extra box within name field → Edit bookmark in Bookmark Contextual Dialog displays extra box within name field for Microsummeries enabled websites
Thanks, Henrik. Since this only happens on OS X, I assume it must be some kind of Cocoa Widgets bug. I'm making it P3 because I think it's a relatively minor annoyance (compared to other bugs that have been marked P1 or P2).
Assignee: nobody → joshmoz
Component: Places → Widget: Cocoa
Priority: -- → P3
Product: Firefox → Core
QA Contact: places → cocoa
Assignee: joshmoz → smichaud
Flags: wanted1.9.0.x?
What part of the appearance is being described as a bug? "Editable menulists shouldn't show focus on the menulist-editable-input"? "Editable menulists shouldn't have padding so the selection highlight will extend to the left and right edges"? "Editable menulists should have a pixel of padding above the menulist-editable-input so they don't look so off-center"? "Editable menulists should have menulist-colored backgrounds on the menulist-editable-input"? (Offhand, I'd expect every one of those other than maybe the last to be purely Toolkit: XUL Widgets.)
Sounds good to me :-) If things turn out otherwise, it can be changed again.
Assignee: smichaud → nobody
Component: Widget: Cocoa → XP Toolkit/Widgets: XUL
QA Contact: cocoa → xptoolkit.xul
Under Vista (Aero) there are shown ugly horizontal and vertical scrollbars when opening the drop down list. Does this also apply to the bug or shall I file a new one?
If it's editable, it really should be using a combobox control (NSComboBox analogue) on Mac OS X instead of a pop-up menu control (NSPopUpButton analogue).
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: xptoolkit.xul → xptoolkit.widgets
Not sure it's worth taking for 1.9.0.x, but definitely for 1.9.1.
Flags: wanted1.9.1?
Flags: wanted1.9.1? → wanted1.9.1+
So what says this is a core bug rather than a toolkit or Firefox bug? Is there a simplified testcase?
Nothing. As I said in comment 4, most of the things it might be about are toolkit, only one of them might be where it started, Widget: Cocoa.
Component: XUL → XUL Widgets
Product: Core → Toolkit
QA Contact: xptoolkit.widgets → xul.widgets
This is a regression from bug 337825. See also bug 429766 comment 6 for more information.
Blocks: 337825
Keywords: regression
So we have three different occurrences of this name field: * Bookmarks contextual dialog * Bookmarks properties dialog * Small Bookmarks properties dialog (Add keyword) All of them are showing the same behavior. While the former 2 occurrences have to show a correctly implemented drop down box we should think about the latter one. Do we really want to show microsummary titles for keywords? I don't think so.
Doesn't really meet the "wanted" criteria (security, stability, regression from maintenance release) for 1.9.0.x. However, we'll look at a reviewed and baked patch.
Flags: wanted1.9.0.x? → wanted1.9.0.x-
Status: NEW → RESOLVED
Closed: 17 years ago
Depends on: 469631
Keywords: fixed1.9.1
Resolution: --- → FIXED
Whiteboard: [fixed by bug 469631]
Target Milestone: --- → mozilla1.9.2a1
Verified fixed with: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090420 Minefield/3.6a1pre ID:20090420031158 Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090421 Shiretoko/3.5b4pre ID:20090421030848
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: