149648 - OPTGROUP element not supported

Status: VERIFIED FIXED

(Camino Graveyard :: HTML Form Controls, defect)

Description

[Chris Petersen]

Build: 2002-06-04-05 trunk
Platform: OS X 10.1.5
Expected Results: Menu should contain a "label" for each optgroup. In this case
, two labels should appear 'Netscape 6.2' and 'Communicator 4.7.9'.
What I got: Labels are missing in OPTGROUP.

Steps to reproduce:

1) Open attached test case
2) Click on optgroup element.
3) Labels are not displayed in popup menu.

Comment 1

[Chris Petersen]

Attachment: Testcase with OPTGROUP element

Comment 2

[saari (gone)]

more forms support
->pinkerton

Comment 3

[Mike Pinkerton (not reading bugmail)]

standards crap, so trivial.

Comment 4

[kaldari]

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

Comment 5

[Sebastian Winkler]

Standards are there to be relied upon, aren't they?
Isn't this going to be fixed?!

Comment 6

[Stuart Morgan]

> Isn't this going to be fixed?!

Presumably yes, since it's marked Assigned->Future, not WONTFIX. But given that
it's future, it wont be fixed until bugs deemed more important (like the 0.8 and
probably 0.9 list) are fixed, unless someone else submits a patch.

There are a lot of bugs; one with very low user impact (in the IE world this is
only supported by 6+, and thus won't be relied upon by the vast majority of web
designers) isn't really a high priority. If you disagree, feel free to submit a
patch for it.

Comment 7

[Sebastian Winkler]

Unfortunately, I'm in no position to do that :(
But, who knows: maybe by the time 0.9 comes around...

Just one opinion for the person who WILL eventually implement this underused but
highly attractive little feature:
I find it's IE5 Mac implementation outstanding!
Maybe imitating it would be an option?!

Comment 8

[louis bennett]

Attachment: testcase

As this test case demonstrates, Camino gets this right for those <select>s with
size > 1, but not those with size = 1.

Comment 9

[Chris Casciano]

-> html form controls

pink, should this still be assigned?

Comment 10

[Simon Fraser [no longer active]]

Taking.

Comment 11

[Simon Fraser [no longer active]]

Attachment: Add support for <optgroup>

Patch is -w, because I added an early return on !sel, and outdented the rest.

Comment 12

[Simon Fraser [no longer active]]

Attachment: Screenshot of testcase with patch

Comment 13

[Mike Pinkerton (not reading bugmail)]

+    [menuItem setRepresentedObject:[NSValue valueWithPointer:option.get()]];

what happens if the node represented by |option| disappears? can this not happen
because we're in a modal runloop tracking the menu and JS execution is suspended?

otherwise looks fine r=pink.

Comment 14

[Simon Fraser [no longer active]]

> what happens if the node represented by |option| disappears

What i'm doing now is no different from stuffing the pointer into the tag, which
the old code did. Also, the rest of this code assumes that the tracking is
synchronous (all the menu items etc are autoreleased).

Comment 15

[Simon Fraser [no longer active]]

Checked in.

Comment 16

[Mike Pinkerton (not reading bugmail)]

still needs to land on the 1.7 branch for 083

Comment 17

[Jon Stevens]

i just downloaded the nightly (2005021408 v0.8+) and tested it with the html
example from this page....

http://www.htmlhelp.com/reference/html40/forms/optgroup.html

things definitely are not showing up properly. maybe this hasn't hit the nightly
copy i just grabbed or something...

Comment 18

[Simon Fraser [no longer active]]

The first build this will be in is the 2/14 build.

Comment 19

[Mike Pinkerton (not reading bugmail)]

landed on branch

Comment 20

[sairuh (rarely reading bugmail)]

this looks good with recent camino trunk bits, eg, 2005031008-trunk NB. if
there's going to be another 0.8.3 branch build soon, I can test there as well.