No, it should not.

Why not? Seems easier to maintain.

(In reply to comment #1) > No, it should not. What's the appropriate way to fix this then Neil? We have the rendering code in native themeing, seems like all we need to do is get the progress xul element to call the right paint routines.

(In reply to comment #3) > (In reply to comment #1) > > No, it should not. > > What's the appropriate way to fix this then Neil? We have the rendering code > in native themeing, seems like all we need to do is get the progress xul > element to call the right paint routines. Fix what? Using -moz-appearance: progressbar; should just display the right appearance. > Why not? Seems easier to maintain. The XBL/Script implementation of the progressmeter is easier for people to maintain and modify than a C++ one. Also, the xul progress meter would be restricted to what the html specification allows the progress meter to do (which we cannot fully control) as opposed to what our UI needs (which we do want to control). This is one problem (among many other problems) that occur with <textbox> being implemented in terms of an html input.

(In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #1) > > > No, it should not. > > > > What's the appropriate way to fix this then Neil? We have the rendering code > > in native themeing, seems like all we need to do is get the progress xul > > element to call the right paint routines. > > Fix what? Using -moz-appearance: progressbar; should just display the right > appearance. > I was experimenting with this yesterday, but couldn't get it to work. For example, in a xul editor: <vbox> <progressmeter style="-moz-appearance: progressbar !important;" mode="undetermined" flex="1" /> </vbox> The style is applied according to dom inspector, but it doesn't change the behavior.

Most/some of my changes in widgets/ are for HTML only to prevent breaking XUL progressmeter. For example, IsIndeterminateProgress() is going to return PR_FALSE if it's called on a XUL element.

(In reply to comment #4) > > Why not? Seems easier to maintain. > > The XBL/Script implementation of the progressmeter is easier for people to > maintain and modify than a C++ one. > > Also, the xul progress meter would be restricted to what the html > specification allows the progress meter to do (which we cannot fully > control) as opposed to what our UI needs (which we do want to control). This > is one problem (among many other problems) that occur with <textbox> being > implemented in terms of an html input. The idea would be to have progressmeter using html:progress for the representation. Everything else would be done in XBL. I do not think the HTML specification is really far from what XBL does (actually, the only think I know to be different is that the XUL element has an attribute to make the progressmeter indeterminate). IMO, that would be easier for everybody: we are already seeing bugs that doesn't behave the same way for the XUL box model and the classic HTML block and some improvements in the native rendering are HTML only for the moment. Except that, I do not really care.