Closed
Bug 110303
Opened 24 years ago
Closed 24 years ago
no "ok" in insert link dialog
Categories
(SeaMonkey :: Composer, defect)
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla0.9.7
People
(Reporter: jud, Assigned: cmanske)
References
Details
(Keywords: regression, Whiteboard: EDITORBASE)
Attachments
(1 file)
|
1.11 KB,
patch
|
kinmoz
:
superreview+
|
Details | Diff | Splinter Review |
using today's trunk build there is no "ok" button when you open the "insert
link" dialog (toolbar or menu item or ctrl-l) (note, my dialog is set to
advanced mode by default).
steps to repro:
1. create a new document in composer
2. add some text.
3. select some text.
4. select "link" from the toolbar
results: the dialog comes up, but, there is no 'ok' , or cancel button at the
bottom.
expected results: the dialog should have those buttons.
after clicking the advanced edit button, the ok and cancel buttons show up.
| Reporter | ||
Updated•24 years ago
|
Keywords: regression
| Reporter | ||
Comment 1•24 years ago
|
||
I meant the "fewer properties" button, not the advanced edit button; sorry.
| Assignee | ||
Comment 2•24 years ago
|
||
Click on the "More / Fewer" button. Do the Ok, Cancel buttons appear?
Assignee: syd → cmanske
| Reporter | ||
Comment 3•24 years ago
|
||
yes
| Assignee | ||
Comment 4•24 years ago
|
||
This is a XUL layout problem. Seems I see this kind of problem more often since
conversion to "<dialog" XUL tag.
Status: NEW → ASSIGNED
| Assignee | ||
Comment 6•24 years ago
|
||
I see this when I start the dialog in the "more" mode, with larger size, but
only the first time the dialog is used. I also see it if the default state is
"less" (smaller), and I click on the "More" button the first time.
| Assignee | ||
Comment 7•24 years ago
|
||
I've done everthing I can think of, and these seem to be an intrinisic sizing
problem. Please investigate!
Assignee: cmanske → danm
Status: ASSIGNED → NEW
*** Bug 111169 has been marked as a duplicate of this bug. ***
| Assignee | ||
Comment 9•24 years ago
|
||
I think the problem is that the "rows" attribute is not used to correctly predict
the height the tree elements (lists) will occupy.
Adding style to set the min-height seems to fix this.
Taking the bug back.
Assignee: danm → cmanske
| Assignee | ||
Comment 10•24 years ago
|
||
| Assignee | ||
Updated•24 years ago
|
Comment 11•24 years ago
|
||
Comment on attachment 58730 [details] [diff] [review]
Add min-height to be sure height of lists are calculated correctly
sr=kin@netscape.com
Attachment #58730 -
Flags: superreview+
Whiteboard: EDITORBASE, FIX IN HAND, need r=,sr= → EDITORBASE, FIX IN HAND, need r=
Comment 12•24 years ago
|
||
r=syd
| Assignee | ||
Comment 13•24 years ago
|
||
checked in
Updated•21 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•