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 257190 - Refactoring, Navigation and Navigator is not working anymore when the files called config.js
Summary: Refactoring, Navigation and Navigator is not working anymore when the files c...
Status: REOPENED
Alias: None
Product: javascript
Classification: Unclassified
Component: Editor (show other bugs)
Version: 8.2
Hardware: PC Other
: P2 normal with 1 vote (vote)
Assignee: Svata Dedic
URL:
Keywords:
: 257617 257642 258776 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-12-17 11:37 UTC by ChrisLE
Modified: 2017-06-28 13:02 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description ChrisLE 2015-12-17 11:37:43 UTC
Create a HTML5 project and add a new file called config.js.
If you have this piece of code:

var test = function() {
    
};

test();

Refactoring (Renaming the functionname), Navigation (ctrl + click on test(), navigates to test =...) and the navigator is not working anymore. This is the smallest piece of project which you can have. But I have a big angular project with a file called config.js and now it is not possible to refactor method or variable names, can't navigate anymore inside the file and the navigator shows nothing.


Regards

Chris
Comment 1 Petr Pisl 2015-12-28 15:42:15 UTC
This doesn't work "just" in the config.js files and the reason is that such js file has mimetype text/karmaconf+javascript and the implementation of org.netbeans.modules.csl.editor.hyperlink.GoToSupport in getResultIterator method doesn't count with this. This is probably a regression introduced with karma support, when these files get extended karma mimetype  -> cc'ing Tomas. 

I have done a simple fix in csl. In the method getResultIterator is checked, whether the required mimetype is not an inherited type from the mimetype path assigned to the snapshot / source. This work in this case, because the inherited type is really text/javascript. But I think that this method should be corrected to support more general mimetype inheritance. I'm cc'ing Svata to be aware of this fix. Svato is it ok?

http://hg.netbeans.org/web-main/rev/98a4c8c9e3a8

This should be fixed in the patch for NB 8.1. Probably for the patch the my fix is sufficient. What do you think?
Comment 2 Quality Engineering 2015-12-29 02:25:16 UTC
Integrated into 'main-silver', will be available in build *201512290002* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)

Changeset: http://hg.netbeans.org/main-silver/rev/98a4c8c9e3a8
User: Petr Pisl <ppisl@netbeans.org>
Log: #257190 - Refactoring, Navigation and Navigator is not working anymore when the files called config.js
Comment 3 Tomas Mysik 2016-01-04 08:37:20 UTC
(In reply to Petr Pisl from comment #1)
> This doesn't work "just" in the config.js files and the reason is that such
> js file has mimetype text/karmaconf+javascript and the implementation of
> org.netbeans.modules.csl.editor.hyperlink.GoToSupport in getResultIterator
> method doesn't count with this. This is probably a regression introduced
> with karma support, when these files get extended karma mimetype  -> cc'ing
> Tomas.

We already use this type of registration for some more files, e.g. bower.json (MIME: text/bower+x-json), so I guess the problem was there as well.

Thanks Petře!
Comment 4 ChrisLE 2016-01-04 08:44:49 UTC
Thx to you, sounds plausible to me, why this happen but yes, a JS file or a json file is still a js or json file. In this case for karma and bower a special json or js file.
Comment 5 Jiri Prox 2016-01-18 16:50:22 UTC
verified in trunk
Comment 6 Petr Pisl 2016-01-22 23:24:13 UTC
Transplanted to the releases / release81:

http://hg.netbeans.org/releases/rev/b930471d6680
Comment 7 Jiri Kovalsky 2016-02-08 16:52:32 UTC
According to Christian's latest update via e-mail the bug is not fixed even in trunk. Thus reopening.
Comment 8 Petr Pisl 2016-06-17 13:21:53 UTC
I have fixed the instant rename action 
http://hg.netbeans.org/web-main/rev/c535b6ad73ba

But, I'm not sure, whether fixing all these actions is a good solution. CC'ing Svata, who understand to CLS more. Svato, what do you think?

Also still navigator is not fixed.
Comment 9 Quality Engineering 2016-06-18 03:11:46 UTC
Integrated into 'main-silver', will be available in build *201606180002* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)

Changeset: http://hg.netbeans.org/main-silver/rev/c535b6ad73ba
User: Petr Pisl <ppisl@netbeans.org>
Log: #257190 - Refactoring, Navigation and Navigator is not working anymore when the files called config.js
Comment 10 Petr Pisl 2016-07-19 12:38:57 UTC
*** Bug 258776 has been marked as a duplicate of this bug. ***
Comment 11 Petr Pisl 2016-07-19 12:40:40 UTC
Svato, do you want to look at this? :) The main problem now is the navigator.
Comment 12 Petr Pisl 2016-07-19 14:36:15 UTC
*** Bug 257617 has been marked as a duplicate of this bug. ***
Comment 13 Svata Dedic 2016-07-26 07:21:42 UTC
This will be a little tough: unlike all the other APIs, Navigator does not use (editor) MIME Lookup, but registers panels using its own impl.

As I went through the reg code, the entire panel registry should be probably updated, as it for example does not refresh when new modules are installed, is not thread-safe etc.

editor.mimelookup does not export API to construct MIME lookup over other area than Editors/* which is not suitable for Navigator.

I see two solutions: 

1/ hack a quick & dirty implementation of cascading mime-based search similar to MimeLookup into the Navigator impl: I could IMHO use MimePath parsing capabilities to enumerate constituent MIMEs. 

2/ create a new API, something like MimeLookup.create(String rootFolder, String providerTag) which would, at the discretion of the caller, create full featured cascading Lookup over another folder hierarchy, using MimeDataProviders registered in a specific (sub)folder etc. Possibly useful in general, as MimeLookup is anything but trivial.

In either case, we may have an issue with too many panels: suppose there's a navigator Panel registered for text/javascript, then another one for text/grunt+javascript. 
The navigator API seems to anticipate multiple registrations for a given content(mime) type - individual panels are then selectable form the navigator. The most specific mime type will surely appear first. The question is whether such presentation is desirable - for example Grunt presentation may need to hide/override some of the generic panels. We do not have any mechanism for that.

Opinions ?
Comment 14 Tomas Mysik 2016-07-26 08:08:55 UTC
(In reply to Svata Dedic from comment #13)
> for example Grunt
> presentation may need to hide/override some of the generic panels.

Please note that Grunt and Gulp have now their own "special" Navigator windows - they show their tasks [1].

Thanks.
[1] http://wiki.netbeans.org/NewAndNoteworthyNB82#Grunt.2FGulp
Comment 15 Svata Dedic 2016-07-26 08:46:37 UTC
Understood, they are registered with @NavigatorPanel.Registration, right ? The reason why nothing appears (for example) for text/bower+x-json or text/karmaconf+javascript (= config.js file) is that no Panel is registered specifically for that content/mime. 

The algorithm for actions, ... use a series of MIME types (text/karmaconf+javascript, then text/javascript) to locate either the most specific impl or at least order impl from the most to least specific.
Navigator currently looks only for the most specific registration, which is typically missing.
Comment 16 Tomas Mysik 2016-07-26 09:38:05 UTC
(In reply to Svata Dedic from comment #15)
> Understood, they are registered with @NavigatorPanel.Registration, right ?

Yes, exactly.
Comment 17 Tomas Mysik 2016-08-11 10:16:01 UTC
*** Bug 257642 has been marked as a duplicate of this bug. ***
Comment 18 ChrisLE 2016-09-05 14:08:19 UTC
Can't set breakpoints into this file too.
Comment 19 ugagga 2016-10-06 10:07:29 UTC
Is there no way to disable the karma module to get rid of this problem? Really weird behavior, especially if you don't need karma at all. Every file containing the string 'conf' in its filename is concerned, quite an interesting way to implement such things
Comment 20 ChrisLE 2016-12-12 13:13:31 UTC
It is still a problem in 8.2 and a pain in the ass.
Comment 21 ChrisLE 2017-05-03 11:35:35 UTC
Anything new here?
Comment 22 Sergey Petrov 2017-06-28 13:02:22 UTC
when everybody are working in nb, you can avoid this, but if there is mixed environment and others create a lot of *conf* files, I probably have to migrate to ide with proper 'conf' files support