This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 142254 - incorrect items invoked by code completion
Summary: incorrect items invoked by code completion
Status: RESOLVED FIXED
Alias: None
Product: web
Classification: Unclassified
Component: CSS Visual Tools (show other bugs)
Version: 6.x
Hardware: Sun All
: P4 blocker (vote)
Assignee: Marek Fukala
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-07-30 15:42 UTC by Jindrich Sedek
Modified: 2011-12-04 13:22 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
patch solving the problem (1.83 KB, text/plain)
2008-11-17 02:59 UTC, David Konecny
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jindrich Sedek 2008-07-30 15:42:40 UTC
use this code:
---------------------
SPAN {
   background: bottom aqua |;
}
----------------------
invoce cc at possition of "|"
center, left, right are invoked in cc as items from background-possition, but it should not since background-possition 
was already filled by "bottom" value
Comment 1 Jindrich Sedek 2008-08-05 11:00:20 UTC
probably the same problem with border-style, but I'm not sure so adding this case as well

h1{
    border: red dashed medium  dashed dashed groove dotted double |;
}
Comment 2 Marek Fukala 2008-08-08 11:41:15 UTC
there is PropertyModelTest.testJindrasCase() testcase for this issue.
Comment 3 David Konecny 2008-11-17 02:59:52 UTC
Created attachment 73809 [details]
patch solving the problem
Comment 4 David Konecny 2008-11-17 03:05:58 UTC
First mentioned issue is actually not an issue: background as well as background-position can have two values. So
suggesting "center, left, right" in correct.

Second problem - border - was wrong: border can have just one border-style/border-width value which is set on all borders.

Attached patch fixes it. Marek, could you review please?

Comment 5 Marek Fukala 2008-11-19 14:18:09 UTC
The first issue reported by Jindra is correct. You cannot offer another members of the background-position group once
one of them already been used before different member of the background group. The bug is in the code computing
alternatives from the grammar and editor context. See the unit tests.

As for the second issue, you are right there is a bug, but much bigger than it may seem. If one group refers to another
group and the referred group is declared as multiplicity of itself we automatically add these possibilities to the
original group which is wrong.

Example: Border -> Border-style -> Border-style{1,4} so currently we allow the border to be border-style{1,4} which is
invalid. This mechanism is fine if the group doesn't define multiplicity of itself.

This needs to be fixed in the grammar parser-model. Even the fix fixes the concrete problem, I would't recommend to
apply it. I'll rather fix the model.

Thanks for the effort anyway David.
Comment 6 David Konecny 2008-11-19 21:55:17 UTC
RE. "PropertyModelTest.testJindrasCase()" - I think the test is wrong. The rule should have been "[ [ x | y ] || b" and
not "[ [ x || y ] || b" - double pipe character means ANY OF and single pipe means ONE OF. I could not reproduce
Jindra's issue in editor anyway. Apart from part which was caused by second (multiplicity) issue. Changing the test rule
makes it pass.

Re. "This needs to be fixed in the grammar parser-model." - you mean for example parser would ignore all multiplicity
attributes in definition of border-style when border-style is used within a different rule, eg. within border? That
might be tricky, no? Sometimes (I could not find any case though) it might be desirable to keep multiplicity even in
parent rules. I still think the rules file is at fault - if you do not want multiplicity in parent rule then define it
that way.
Comment 7 Marek Fukala 2008-11-21 18:43:52 UTC
You do not see the background-position group members in the css invoked on the pipe position?

   background: bottom aqua  |;

Lucky man. How the hell you do it? :-)

Davide, belive me the test is correct. The point here is that if you have a 'set' group [A || B || C] and you match the A (regardless of its internal structure), 
then match B or C so then you cannot offer other member of the A group even if some of them were possible before you matched the B or C.

The test grammar tests this: [ x || y ] || b (there was one extra [ bracket (ignored)). 

If you complete x, you can complete y or b, but if you complete x b, you cannot go back and complete y, the whole group [x || y] was resolved by x.

Passes: x, y, b, xy, yx, xyb, yxb, xb, yb but NOT: xbx, xby,ybx, yby.

Doesn't it make sense now? Or am I completely out? Please not that the  background: bottom aqua  center; value is invalid css code, you can check it in 
css w3c validator.

>Sometimes (I could not find any case though)
find the cases and then we can think something up, but fixing all these cases in the grammar is overkill, do not do that please.










Comment 8 David Konecny 2008-11-24 00:54:14 UTC
Got it - I did not pay enough attention to *order*. Thanks for the patience with me. I agree that "[ x || y ] || b" case
is error in grammar parser. I still think multiplicity is OK and it is our grammar file which needs to be fixed - it is
just couple of cases. But that's just my opinion, no strong argument. Thanks Marek.
Comment 9 Marek Fukala 2010-04-19 13:13:14 UTC
Normal users don't complain about this issue, not simple fix.
Comment 10 Marek Fukala 2011-12-04 13:22:15 UTC
already fixed