Created attachment 105539 [details]
Page to copy to

caused by the wicket namespace declaration.

another example to reproduce the  SIOOB is the ${nb_repo_home}/openide.util.lookup/src/org/openide/util/lookup/doc-files/index.html reported in the issue 192713

It is an internal validator error occurring even in the latest validator.nu version.

Is there a chance raise priority to 2?

As a wicket developer, I depend on the validator in the editor, which is so quite broken (works in 9.1).

I would love to keep using the daily builds for testing and bug reporting :)

What exactly is *broken*? Except the annotation at the beginning of the file there is no user impact of that issue. Of course except the file not being validated ;-) BTW the exception neither pops un in the editor nor is logged with INFO level.

Subsequent validation breaks. The editor does not allow me to collapse elements and so on. Quite a lot is broken actually.

Please consider that I reported another bug (now fixed) that appears to have prevented this from showing. Are you sure that there is not a third validation bug that shows only after this is fixed?

What do you mean by prevented from showing? Do you mean that the issue is not occurring at all or just not popping up in the exception dialog and being logged? 

I suppose you mean this one: Bug 194618 - Error parsing simple valid HTML.

These two are unrelated.

I've recently modified the logging of the validator issues so the known exceptions like this one are logged just in FINE level so in fact they are not presented to the user at all. However this doesn't mean the issue is not there.

What I mean by that is that even though unrelated, the other issue prevented this from occuring.

That may not necessarily be reflected in the testcase, but in my production files. If that is the case then it may just take too long to get the parser fully tested and fixed in time. Therefore, and because of the fact that this error did not appear in 6.9, I am suggesting to raise the priority.

I noticed that the error handling was changed and I appreciate this. But it does not seem to change the behavior of the parser.

I am raising the priority to 2 because I think that priority 2 ensures that NetBeans will not be released with this bug included.

Please let me summarize the state of this issue:
1) there is a bug in the html validator causing the html code validation doesn't work *fully* for some pages. Even if the problem occurs there are some errors reported for the page.
2) apart from the above the user consequence is that the file is marked as errorneous - an error annotation is shown at the very first line saying "internal error occurred ..."
3) the validation problem has *absolutely no influence* to any other editor functionality. No feature is built on top of it. So code completion, coloring, indentation etc. does work normally.
4) I noticed that there are no folds for the page - that is different P3 issue.

My solution for now is:
#1 - investigate why the problem in the validator happens and possibly report it to Henri Sivonen who is the author of the validator. I doesn't seem to be fixable within 7.0 timeframe

#2 - I'll change the annotation type so the file "correctness" status won't be "error" but unchanged by this issue

#4 - I've filled a P3 Bug 196292 - No code folds for some specific files

With respect to the above I do not agree with this issue being P2. In my opinion the consequence is minimal and it is not a regression from 6.9. I'm going to fix the #2 now...

#2 (status of the file w/ the internal error) fixed in web-main#33ace80778fa

Actually I was wrong about the #3 - there is a connection. Since the validator adds its errors to the html parser results there may be a consequences in the editor features. And that was exactly the case of folding - I didn't know there's something like if(errors_in_code) { do_not_show_folds; } in the GsfFoldManager. Since I've changes the error type for the internal error just to INFO level, the folds are back now.

The code completion behavior used to be affected by the internal error as well since it triggered some fallback code active if the parse tree is broken.

BHT, can you please verify the behavior after the fix and verify it helps?? Please use the build with the fix which is going to be put here by the building process. Thanks in advance and let me apologize a bit!

Integrated into 'main-golden', will be available in build *201103080000* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/33ace80778fa
User: Marek Fukala <mfukala@netbeans.org>
Log: #194939 - StringIndexOutOfBoundsException when declaring wicket namespace

Created attachment 106839 [details]
Testcase

Marek,
Thanks very much for addressing the issue. I have attached a test file that may show the problem a little better. It works fine in NetBeans 6.9.

May be My comments were confusing.

It still does not work.

As for the folding, you are right, there are other ERRORs in the file causing the folding to be disabled. I do not why but it seemed to me it works well after the change I did before. 

If you take a build with the fix of Bug 196632 - Unknown attribute breaks other editor functionality you should be able to get the folds. The issue makes all the html validator problems warnings only and hence the folding state is unaffected.

I'm sorry for the confusion.

BTW any other problems apart from the folding? There shouldn't be any. If they are please specify exactly what and where doesn't work and how can I reproduce. Please use steps like 1) open file xxx, 2) put caret to 10:5, 3) do something else => something doesn't work. Thanks for your understanding.

I have had some more time working with the fixed build.

As a consequence of the fix, some HTML errors, possibly due to the name-spaced tags are now no longer flagged as errors but as warnings.

For example, if you try in the attachment "Testcase":
            <tr wicket:id="idRow">
                <th colspan="2">ID:</td>
                <td colspan="2" wicket:id="id">12356</td>
            </tr>

(the first <th> is unmatched (incorrectly matched by </td>)

then there is a yellow warning icon not a red one as in version 9.1.

I think we need the error flagging for the real HTML errors otherwise one cannot see that the file is invalid as a whole.

I found this when I missed a </html> tag and the file was still valid.

You can try this with the testcase and there is no red icon as a conseequence.

I don't know whether this name space filtering is the final solution. Not name spaced content enclosed by name space filtered tags is hidden, which means in case of the testcase, the content within the <head> section is missing, therefore causing warnings and the lack of proper validation.

I don't know how NB6.9 does it, but I could imagine that name spaced tags are kept in a separate space so that they don't interfere with others but still are validated for nesting, closing etc..

Needs to be resolved or waived for NB 7.0

The original issue has been already fixed. The latest user complain has been filed as new issues:

Bug 197144 - Namespaces filtering problem
Bug 197145 - Html validator doesn't flag a file as erroneous 

bht, file the problems as new issues since this way we cannot track them properly.