Bug 68024 - table: evaluates <text:variable-set> in body of float and void cells, but not of string cells
Summary: table: evaluates <text:variable-set> in body of float and void cells, but not...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.2.0.0.alpha0+ Master
Hardware: All All
: medium normal
Assignee: Michael Stahl
QA Contact:
URL:
Whiteboard: odf
Keywords: bibisected, bisected, regression
Depends on:
Blocks: 68020 67930
  Show dependency treegraph
 
Reported: 2013-08-12 14:24 UTC by Lionel Elie Mamane
Modified: 2016-09-26 15:21 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Lionel Elie Mamane 2013-08-12 14:24:02 UTC
Consider attachment 83968 [details]

In the first three rows, the body is always displayed (in these cases,
the office:value attributes properly overrides the child text:p),
but it is always *treated* in some way. In particular, <text:variable-set>
tags are treated. See that variables (foo|bar)Apr(Pri|Sec) as well as
(foo|bar)AugPri are set, and displayed in the page footer:
 f41-b41,f42-b42,f81-b81

On the other hand, for cells with office:value-type="string"
(rows August Secundo and August Tertio), as soon as there is
an office:string-value (that is, the second column), the
<text:variable-set> in the body are not evaluated; the variables
fooAug(Sec|Ter) stay at "0". This is what causes bug 67930. In the
absence of an office:string-value, however, the body is displayed
and executed, and the barAug(Sec|Ter) variables do get set.

It should be coherent, and *always* evaluate <text:p> within
each body.
Comment 1 Lionel Elie Mamane 2013-08-12 14:28:04 UTC
Actually, even <text:variable-set> in a cell of type void is evaluated.
Comment 2 Lionel Elie Mamane 2013-08-12 14:55:29 UTC
This is a regression compared to 3.5.4.2; most probably introduced by the fix to bug 60842:

http://cgit.freedesktop.org/libreoffice/core/commit/?id=1b5839f49c07beb6fbde6c7370a5636d22f9ab77

fdo#60842: sw ODF import: support value-type="string" on cells
Comment 3 Robinson Tryon (qubit) 2014-01-16 15:19:59 UTC
Lionel - Who should address this bug?
Comment 4 Lionel Elie Mamane 2014-01-16 15:41:20 UTC
(In reply to comment #3)
> Lionel - Who should address this bug?

I hoped that Michael Stahl would address it, since he addresses similar / related bugs. Failing that, some other Writer hacker / expert / ...?
Comment 5 Robinson Tryon (qubit) 2014-02-03 19:00:09 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > Lionel - Who should address this bug?
> 
> I hoped that Michael Stahl would address it, since he addresses similar /
> related bugs. Failing that, some other Writer hacker / expert / ...?

Sounds good.

In general, QA has been using the 'NeedAdvice' tag to mark bugs that need to be escalated up for a dev to evaluate. I'd like to see bugs be addressed by a dev within perhaps a month of being tagged -- having bugs sit in this state for months at a time makes it harder for us to filter on this tag and get a list of actionable bugs.

I'd appreciate it if anyone who tags a bug as NeedAdvice makes sure to follow-up on the bug at least once a month and see what they can do to spur our existing devs to comment on the results. If a bug really isn't actionable for a while, I'd be open to introducing a new tag 'NeedAdviceInTheFuture' to separate-out these particular outliers.

Thanks!
Comment 6 Robinson Tryon (qubit) 2014-07-03 20:29:57 UTC
(Removing NeedAdvice tag)

Lionel - Please feel free to set the status of these regressions directly to NEW.
Comment 7 Björn Michaelsen 2014-10-16 14:59:03 UTC
(This is an automated message.)

It seems that the commit that caused this regression was identified. (Or at least a commit is suspected as the offending one.)

Thus setting keyword "bisected".
Comment 8 Michael Stahl 2014-12-12 15:40:48 UTC
sigh... retyping comment since bugzilla ate it...

that we import the field for value-type="float" or value-type="void"
sounds like a bug to me.

ODF 1.2 19.385 office:value-type is quite clear that the value 
from office:string-value takes precedence over the element content.

the value of the table cell would include any fields or other
formatting in the element text, which obviously can't be
encoded in an XML attribute.

so from that it doesn't make sense to add an office:value-type
attribute on a cell that has content that isn't just plain text.

another point of view would be that the ODF spec has a bug here
and that office:string-value should not take precedence over the
element content.

office:value-type="string" already differs from the other types
in that for the other types the *-value attribute is mandatory and
the element content is merely a "preview" text rendering for "dumb"
consumers with some particular # of digits etc.,
which is not a concern if the type is string.
Comment 9 Michael Stahl 2014-12-12 16:24:33 UTC
was wondering why the office:string-value exists at all;
Eike said that you can create a number format like this:
@ "foo"
and it will append "foo" to the text in the cell.

Calc implements this well, in Writer you can do this
in the UI but if you look at the exported ODF file it's
quite some nonsense :(
Comment 10 Michael Stahl 2014-12-12 16:27:39 UTC
(In reply to Michael Stahl from comment #8)
> so from that it doesn't make sense to add an office:value-type
> attribute on a cell that has content that isn't just plain text.

of course i meant "office:string-value" here.
Comment 11 Lionel Elie Mamane 2014-12-17 07:40:22 UTC
(In reply to Michael Stahl from comment #9)
> was wondering why the office:string-value exists at all;
> Eike said that you can create a number format like this:
> @ "foo"
> and it will append "foo" to the text in the cell.

And then, if there were no office:string-value, the original value (pre-formatting) would be "lost" (or, let's say, unduly hard to retrieve), since only the post-formatting result would be stored in the file.

This works only for non-formatted strings; this is obvious from the POV of the file format, but IMHO quite surprising for the "naive" user. <shrug>
Comment 12 Lionel Elie Mamane 2014-12-17 09:51:10 UTC
(In reply to Michael Stahl from comment #8)

> that we import the field for value-type="float" or value-type="void"
> sounds like a bug to me.

<big sigh> Report Builder relies on it :-|
Comment 13 Joel Madero 2015-01-05 17:16:29 UTC
Adding bibisected to whiteboard as bisected keyword is a subset of bibisected whiteboard.

Thanks!
Comment 14 Michael Stahl 2015-02-03 09:33:13 UTC
about the handling of "float" fields, see my comment on bug 68022
Comment 15 Robinson Tryon (qubit) 2015-12-14 05:06:28 UTC
Migrating Whiteboard tags to Keywords: (bibisected)
[NinjaEdit]
Comment 16 Xisco Faulí 2016-09-26 15:21:17 UTC
Adding Cc: to Michael Stahl