In SELECT, if standard_widget_colors is set, color and backgroundColor are set to NULL. This tells FltkResource::setWidgetStyle() to leave the colors on the widget alone. If an inline element inside a SELECT calls style->color->getColor() or style->backgroundColor->getColor(), we get that crash. This currently means FONT and IMG. OBJECT and A would as well if that a_Color_vc code were uncommented. options: - four IN_SELECT tests. - letting Html_stack_cleanup_at_open() be called for inline elements in order to close the SELECT or something if IN_SELECT and the new tag isn't OPTION or OPTGROUP. - generating our own standard widget colors to put into color and backgroundColor. I don't like the first one because someone innocently adding a getColor somewhere in the future will never know about this danger. (a good example would be adding the a_Color_vc to open_frame())
On Mon, Jun 23, 2008 at 05:05:29AM +0000, corvid wrote:
In SELECT, if standard_widget_colors is set, color and backgroundColor are set to NULL. This tells FltkResource::setWidgetStyle() to leave the colors on the widget alone.
This is done for most input types in form.cc, not just SELECT, see: * Html_tag_open_input() * Html_tag_open_isindex() * Html_tag_open_select() However it is not done in: * Html_tag_open_button() * Html_input_image() Is the potential crash only an issue for SELECT inputs? If so, why?
If an inline element inside a SELECT calls style->color->getColor() or style->backgroundColor->getColor(), we get that crash.
There's dw::core::Widget::getBgColor() , which chains up the widget hierarchy looking for a non-NULL background color. Perhaps we should be calling that? However there is no equivalent (that I can see) for foreground colors. Perhaps there should be? Regards, Jeremy Henty
Jeremy wrote:
On Mon, Jun 23, 2008 at 05:05:29AM +0000, corvid wrote:
In SELECT, if standard_widget_colors is set, color and backgroundColor are set to NULL. This tells FltkResource::setWidgetStyle() to leave the colors on the widget alone.
This is done for most input types in form.cc, not just SELECT, see: * Html_tag_open_input() * Html_tag_open_isindex() * Html_tag_open_select()
However it is not done in: * Html_tag_open_button() * Html_input_image()
The first three show fltk widgets.
Is the potential crash only an issue for SELECT inputs? If so, why?
INPUT and ISINDEX don't have close tags, so other tags can't be sneaked inside them.
If an inline element inside a SELECT calls style->color->getColor() or style->backgroundColor->getColor(), we get that crash.
There's dw::core::Widget::getBgColor() , which chains up the widget hierarchy looking for a non-NULL background color. Perhaps we should be calling that? However there is no equivalent (that I can see) for foreground colors. Perhaps there should be?
I guess the getColor()s could go in something that goes up the DilloHtmlState stack looking for non-NULL...
On Mon, Jun 23, 2008 at 10:01:43AM +0000, corvid wrote:
Jeremy wrote:
On Mon, Jun 23, 2008 at 05:05:29AM +0000, corvid wrote:
In SELECT, if standard_widget_colors is set, color and backgroundColor are set to NULL. ...
This is done for most input types in form.cc, not just SELECT, see: * Html_tag_open_input() * Html_tag_open_isindex() * Html_tag_open_select()
However it is not done in: * Html_tag_open_button() * Html_input_image()
The first three show fltk widgets.
Hmm, whereas the other two create a ComplexButtonResource that does not.
Is the potential crash only an issue for SELECT inputs? If so, why?
INPUT and ISINDEX don't have close tags, so other tags can't be sneaked inside them.
Thanks for that. This is the bit of form.cc that I understand least which is why I have all these questions. I want to refactor the various code paths that lead to AddInput() but every time I look I see more ways in which they do things differently. The paths that call Html_tag_open_button() and Html_input_image() are particularly tricky and refactoring them correctly depends on understanding the DilloHtml stack, widget styles and layouts etc. Regards, Jeremy Henty
On Mon, Jun 23, 2008 at 05:05:29AM +0000, corvid wrote:
In SELECT, if standard_widget_colors is set, color and backgroundColor are set to NULL. This tells FltkResource::setWidgetStyle() to leave the colors on the widget alone.
If an inline element inside a SELECT calls style->color->getColor() or style->backgroundColor->getColor(), we get that crash.
This currently means FONT and IMG. OBJECT and A would as well if that a_Color_vc code were uncommented.
options: - four IN_SELECT tests. - letting Html_stack_cleanup_at_open() be called for inline elements in order to close the SELECT or something if IN_SELECT and the new tag isn't OPTION or OPTGROUP. - generating our own standard widget colors to put into color and backgroundColor.
I don't like the first one because someone innocently adding a getColor somewhere in the future will never know about this danger. (a good example would be adding the a_Color_vc to open_frame())
Without a deep understanding of the code involved, I'd prefer the third option (standard widget colors) as it looks more general and simple as a solution. -- Cheers Jorge.-
Jorge wrote:
On Mon, Jun 23, 2008 at 05:05:29AM +0000, corvid wrote:
In SELECT, if standard_widget_colors is set, color and backgroundColor are set to NULL. This tells FltkResource::setWidgetStyle() to leave the colors on the widget alone.
If an inline element inside a SELECT calls style->color->getColor() or style->backgroundColor->getColor(), we get that crash.
This currently means FONT and IMG. OBJECT and A would as well if that a_Color_vc code were uncommented.
options: - four IN_SELECT tests. - letting Html_stack_cleanup_at_open() be called for inline elements in order to close the SELECT or something if IN_SELECT and the new tag isn't OPTION or OPTGROUP. - generating our own standard widget colors to put into color and backgroundColor.
I don't like the first one because someone innocently adding a getColor somewhere in the future will never know about this danger. (a good example would be adding the a_Color_vc to open_frame())
Without a deep understanding of the code involved, I'd prefer the third option (standard widget colors) as it looks more general and simple as a solution.
All right.
participants (3)
-
corvid＠lavabit.com -
jcid＠dillo.org -
onepoint＠starurchin.org