phpMyAdmin

Bugs item #3529605, was opened at 2012-05-24 15:42
Message generated for change (Comment added) made by lem9
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377408&aid=3529605&group_id=23067

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Browser/W3C/JS compatibility
Group: 3.5.1
>Status: Pending
Resolution: None
Priority: 5
Private: No
Submitted By: Varun Varada (getsnoopy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Trailing Newline after PHP End Tag Causes Malfunction

Initial Comment:
It seems like every single PHP file in the 3.5.1 version has a trailing newline after the PHP end tag, so when libraries are being included, this newline causes the browser to force a text/html type on the resulting page.

This causes the /js/get_images.js.php file to incorrectly send out the text/html content-type header, which renders all of the output JavaScript to be invalid (due to the DOCTYPE tag being assumed by the browser, which is not valid JavaScript, causing a syntax error). Effectively, this whole script does not work and the page has a lot of the functionality compromised.

Please remove these trailing newlines as soon as possible.

----------------------------------------------------------------------

>Comment By: Marc Delisle (lem9)
Date: 2012-05-25 04:42

Message:
I verified with Firefox 12.0 on Windows XP + Firebug 1.9.2. The
content-type header returned by js/get_images.js.php is

text/javascript; charset=UTF-8

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377408&aid=3529605&group_id=23067

Bugs item #3529605, was opened at 2012-05-24 15:42
Message generated for change (Comment added) made by getsnoopy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377408&aid=3529605&group_id=23067

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Browser/W3C/JS compatibility
Group: 3.5.1
>Status: Open
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Varun Varada (getsnoopy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Trailing Newline after PHP End Tag Causes Malfunction

Initial Comment:
It seems like every single PHP file in the 3.5.1 version has a trailing newline after the PHP end tag, so when libraries are being included, this newline causes the browser to force a text/html type on the resulting page.

This causes the /js/get_images.js.php file to incorrectly send out the text/html content-type header, which renders all of the output JavaScript to be invalid (due to the DOCTYPE tag being assumed by the browser, which is not valid JavaScript, causing a syntax error). Effectively, this whole script does not work and the page has a lot of the functionality compromised.

Please remove these trailing newlines as soon as possible.

----------------------------------------------------------------------

>Comment By: Varun Varada (getsnoopy)
Date: 2012-05-25 11:19

Message:
Although having the newlines is still a problem, it seems like they weren't
causing the issue. The tidy PHP extension seems to have been the culprit,
and removing it resolved the issue.

Thank you for your effort

----------------------------------------------------------------------

Comment By: Marc Delisle (lem9)
Date: 2012-05-25 04:42

Message:
I verified with Firefox 12.0 on Windows XP + Firebug 1.9.2. The
content-type header returned by js/get_images.js.php is

text/javascript; charset=UTF-8

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377408&aid=3529605&group_id=23067

Bugs item #3529605, was opened at 2012-05-24 15:42
Message generated for change (Comment added) made by lem9
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377408&aid=3529605&group_id=23067

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Browser/W3C/JS compatibility
Group: 3.5.1
Status: Open
Resolution: Accepted
Priority: 5
Private: No
Submitted By: Varun Varada (getsnoopy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Trailing Newline after PHP End Tag Causes Malfunction

Initial Comment:
It seems like every single PHP file in the 3.5.1 version has a trailing newline after the PHP end tag, so when libraries are being included, this newline causes the browser to force a text/html type on the resulting page.

This causes the /js/get_images.js.php file to incorrectly send out the text/html content-type header, which renders all of the output JavaScript to be invalid (due to the DOCTYPE tag being assumed by the browser, which is not valid JavaScript, causing a syntax error). Effectively, this whole script does not work and the page has a lot of the functionality compromised.

Please remove these trailing newlines as soon as possible.

----------------------------------------------------------------------

>Comment By: Marc Delisle (lem9)
Date: 2012-05-25 12:11

Message:
What other problem are the newlines causing?

----------------------------------------------------------------------

Comment By: Varun Varada (getsnoopy)
Date: 2012-05-25 11:19

Message:
Although having the newlines is still a problem, it seems like they weren't
causing the issue. The tidy PHP extension seems to have been the culprit,
and removing it resolved the issue.

Thank you for your effort

----------------------------------------------------------------------

Comment By: Marc Delisle (lem9)
Date: 2012-05-25 04:42

Message:
I verified with Firefox 12.0 on Windows XP + Firebug 1.9.2. The
content-type header returned by js/get_images.js.php is

text/javascript; charset=UTF-8

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377408&aid=3529605&group_id=23067

Bugs item #3529605, was opened at 2012-05-24 15:42
Message generated for change (Comment added) made by lem9
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377408&aid=3529605&group_id=23067

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Browser/W3C/JS compatibility
Group: 3.5.1
>Status: Deleted
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Varun Varada (getsnoopy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Trailing Newline after PHP End Tag Causes Malfunction

Initial Comment:
It seems like every single PHP file in the 3.5.1 version has a trailing newline after the PHP end tag, so when libraries are being included, this newline causes the browser to force a text/html type on the resulting page.

This causes the /js/get_images.js.php file to incorrectly send out the text/html content-type header, which renders all of the output JavaScript to be invalid (due to the DOCTYPE tag being assumed by the browser, which is not valid JavaScript, causing a syntax error). Effectively, this whole script does not work and the page has a lot of the functionality compromised.

Please remove these trailing newlines as soon as possible.

----------------------------------------------------------------------

>Comment By: Marc Delisle (lem9)
Date: 2012-05-26 03:36

Message:
P.S. we are following the PEAR coding standard that says:
"There should be one line feed after the closing PHP tag (?>)."

http://pear.php.net/manual/en/standards.file.php

----------------------------------------------------------------------

Comment By: Marc Delisle (lem9)
Date: 2012-05-25 12:11

Message:
What other problem are the newlines causing?

----------------------------------------------------------------------

Comment By: Varun Varada (getsnoopy)
Date: 2012-05-25 11:19

Message:
Although having the newlines is still a problem, it seems like they weren't
causing the issue. The tidy PHP extension seems to have been the culprit,
and removing it resolved the issue.

Thank you for your effort

----------------------------------------------------------------------

Comment By: Marc Delisle (lem9)
Date: 2012-05-25 04:42

Message:
I verified with Firefox 12.0 on Windows XP + Firebug 1.9.2. The
content-type header returned by js/get_images.js.php is

text/javascript; charset=UTF-8

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377408&aid=3529605&group_id=23067

Bugs item #3529605, was opened at 2012-05-24 15:42
Message generated for change (Comment added) made by getsnoopy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377408&aid=3529605&group_id=23067

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Browser/W3C/JS compatibility
Group: 3.5.1
Status: Deleted
Resolution: Invalid
Priority: 5
Private: No
Submitted By: Varun Varada (getsnoopy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Trailing Newline after PHP End Tag Causes Malfunction

Initial Comment:
It seems like every single PHP file in the 3.5.1 version has a trailing newline after the PHP end tag, so when libraries are being included, this newline causes the browser to force a text/html type on the resulting page.

This causes the /js/get_images.js.php file to incorrectly send out the text/html content-type header, which renders all of the output JavaScript to be invalid (due to the DOCTYPE tag being assumed by the browser, which is not valid JavaScript, causing a syntax error). Effectively, this whole script does not work and the page has a lot of the functionality compromised.

Please remove these trailing newlines as soon as possible.

----------------------------------------------------------------------

Comment By: Varun Varada (getsnoopy)
Date: 2012-05-26 09:24

Message:
That is interesting. It just seems like having the extra newline would fail
some applications in some instances.

But I'm not sure if it's causing any other problems.

----------------------------------------------------------------------

Comment By: Marc Delisle (lem9)
Date: 2012-05-26 03:36

Message:
P.S. we are following the PEAR coding standard that says:
"There should be one line feed after the closing PHP tag (?>)."

http://pear.php.net/manual/en/standards.file.php

----------------------------------------------------------------------

Comment By: Marc Delisle (lem9)
Date: 2012-05-25 12:11

Message:
What other problem are the newlines causing?

----------------------------------------------------------------------

Comment By: Varun Varada (getsnoopy)
Date: 2012-05-25 11:19

Message:
Although having the newlines is still a problem, it seems like they weren't
causing the issue. The tidy PHP extension seems to have been the culprit,
and removing it resolved the issue.

Thank you for your effort

----------------------------------------------------------------------

Comment By: Marc Delisle (lem9)
Date: 2012-05-25 04:42

Message:
I verified with Firefox 12.0 on Windows XP + Firebug 1.9.2. The
content-type header returned by js/get_images.js.php is

text/javascript; charset=UTF-8

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377408&aid=3529605&group_id=23067

Bugs item #3523499, was opened at 2012-05-04 05:46
Message generated for change (Comment added) made by nijel
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377408&aid=3523499&group_id=23067

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Browser/W3C/JS compatibility
Group: 3.5.1
Status: Open
Resolution: Fixed
Priority: 1
Private: No
Submitted By: Jan-Kaspar Münnich (dotplex)
Assigned to: Michal Čihař (nijel)
Summary: (ok 3.5.2) 3.5.1 X-WebKit-CSP Header breaks Safari

Initial Comment:
In 3.5.1 the line

header('X-WebKit-CSP: default-src \'self\' \'unsafe-inline\'; img-src \'self\' data:; script-src \'self\' \'unsafe-inline\' \'unsafe-eval\' http://www.phpmyadmin.net');

was added in libraries/header_http.inc.php. This prevents Safari from loading frames and scripts. 

----------------------------------------------------------------------

>Comment By: Michal Čihař (nijel)
Date: 2012-05-17 00:40

Message:
This one should be enough. Or at least it did fix problem for browsers
which I can test. I'm afraid that different Webkit versions parse
differently X-WebKit-CSP. Can you try whether it will work when placing
content of X-Content-Security-Policy into X-WebKit-CSP?

----------------------------------------------------------------------

Comment By: wdauchy (wdauchy)
Date: 2012-05-16 08:06

Message:
I applied commit 4a141a0
(https://github.com/phpmyadmin/phpmyadmin/commit/4a141a067c6b0a04e512ad73dcd86bbd188fa0ab)
on top of a 3.5.1 release but it does not seem to fix the problem. Am I
missing another commit?

----------------------------------------------------------------------

Comment By: Michal Čihař (nijel)
Date: 2012-05-15 05:20

Message:
This bug was fixed in repository and will be part of a future release;
thanks for reporting.

----------------------------------------------------------------------

Comment By: Rouslan Placella (roccivic)
Date: 2012-05-14 08:28

Message:
Quoting brightbeat:

An easy fix currently for content-security-policy can be to add this line
to config.inc.php
$cfg['AllowThirdPartyFraming'] = true;

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377408&aid=3523499&group_id=23067

Bugs item #3523499, was opened at 2012-05-04 05:46
Message generated for change (Settings changed) made by nijel
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377408&aid=3523499&group_id=23067

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Browser/W3C/JS compatibility
Group: 3.5.1
Status: Open
>Resolution: None
>Priority: 5
Private: No
Submitted By: Jan-Kaspar Münnich (dotplex)
Assigned to: Michal Čihař (nijel)
Summary: (ok 3.5.2) 3.5.1 X-WebKit-CSP Header breaks Safari

Initial Comment:
In 3.5.1 the line

header('X-WebKit-CSP: default-src \'self\' \'unsafe-inline\'; img-src \'self\' data:; script-src \'self\' \'unsafe-inline\' \'unsafe-eval\' http://www.phpmyadmin.net');

was added in libraries/header_http.inc.php. This prevents Safari from loading frames and scripts. 

----------------------------------------------------------------------

Comment By: Michal Čihař (nijel)
Date: 2012-05-17 00:40

Message:
This one should be enough. Or at least it did fix problem for browsers
which I can test. I'm afraid that different Webkit versions parse
differently X-WebKit-CSP. Can you try whether it will work when placing
content of X-Content-Security-Policy into X-WebKit-CSP?

----------------------------------------------------------------------

Comment By: wdauchy (wdauchy)
Date: 2012-05-16 08:06

Message:
I applied commit 4a141a0
(https://github.com/phpmyadmin/phpmyadmin/commit/4a141a067c6b0a04e512ad73dcd86bbd188fa0ab)
on top of a 3.5.1 release but it does not seem to fix the problem. Am I
missing another commit?

----------------------------------------------------------------------

Comment By: Michal Čihař (nijel)
Date: 2012-05-15 05:20

Message:
This bug was fixed in repository and will be part of a future release;
thanks for reporting.

----------------------------------------------------------------------

Comment By: Rouslan Placella (roccivic)
Date: 2012-05-14 08:28

Message:
Quoting brightbeat:

An easy fix currently for content-security-policy can be to add this line
to config.inc.php
$cfg['AllowThirdPartyFraming'] = true;

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377408&aid=3523499&group_id=23067

Bugs item #3523499, was opened at 2012-05-04 05:46
Message generated for change (Comment added) made by wdauchy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377408&aid=3523499&group_id=23067

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Browser/W3C/JS compatibility
Group: 3.5.1
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jan-Kaspar Münnich (dotplex)
Assigned to: Michal Čihař (nijel)
Summary: (ok 3.5.2) 3.5.1 X-WebKit-CSP Header breaks Safari

Initial Comment:
In 3.5.1 the line

header('X-WebKit-CSP: default-src \'self\' \'unsafe-inline\'; img-src \'self\' data:; script-src \'self\' \'unsafe-inline\' \'unsafe-eval\' http://www.phpmyadmin.net');

was added in libraries/header_http.inc.php. This prevents Safari from loading frames and scripts. 

----------------------------------------------------------------------

Comment By: wdauchy (wdauchy)
Date: 2012-05-18 03:38

Message:
In fact I got some weird behaviour with safari and random results. After
clearing cache and stuff, it seems to be fixed with your commit. Sorry for
the noise.

----------------------------------------------------------------------

Comment By: Michal Čihař (nijel)
Date: 2012-05-17 00:40

Message:
This one should be enough. Or at least it did fix problem for browsers
which I can test. I'm afraid that different Webkit versions parse
differently X-WebKit-CSP. Can you try whether it will work when placing
content of X-Content-Security-Policy into X-WebKit-CSP?

----------------------------------------------------------------------

Comment By: wdauchy (wdauchy)
Date: 2012-05-16 08:06

Message:
I applied commit 4a141a0
(https://github.com/phpmyadmin/phpmyadmin/commit/4a141a067c6b0a04e512ad73dcd86bbd188fa0ab)
on top of a 3.5.1 release but it does not seem to fix the problem. Am I
missing another commit?

----------------------------------------------------------------------

Comment By: Michal Čihař (nijel)
Date: 2012-05-15 05:20

Message:
This bug was fixed in repository and will be part of a future release;
thanks for reporting.

----------------------------------------------------------------------

Comment By: Rouslan Placella (roccivic)
Date: 2012-05-14 08:28

Message:
Quoting brightbeat:

An easy fix currently for content-security-policy can be to add this line
to config.inc.php
$cfg['AllowThirdPartyFraming'] = true;

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377408&aid=3523499&group_id=23067

Bugs item #3523499, was opened at 2012-05-04 05:46
Message generated for change (Settings changed) made by nijel
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377408&aid=3523499&group_id=23067

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Browser/W3C/JS compatibility
Group: 3.5.1
Status: Open
>Resolution: Fixed
>Priority: 1
Private: No
Submitted By: Jan-Kaspar Münnich (dotplex)
Assigned to: Michal Čihař (nijel)
Summary: (ok 3.5.2) 3.5.1 X-WebKit-CSP Header breaks Safari

Initial Comment:
In 3.5.1 the line

header('X-WebKit-CSP: default-src \'self\' \'unsafe-inline\'; img-src \'self\' data:; script-src \'self\' \'unsafe-inline\' \'unsafe-eval\' http://www.phpmyadmin.net');

was added in libraries/header_http.inc.php. This prevents Safari from loading frames and scripts. 

----------------------------------------------------------------------

Comment By: wdauchy (wdauchy)
Date: 2012-05-18 03:38

Message:
In fact I got some weird behaviour with safari and random results. After
clearing cache and stuff, it seems to be fixed with your commit. Sorry for
the noise.

----------------------------------------------------------------------

Comment By: Michal Čihař (nijel)
Date: 2012-05-17 00:40

Message:
This one should be enough. Or at least it did fix problem for browsers
which I can test. I'm afraid that different Webkit versions parse
differently X-WebKit-CSP. Can you try whether it will work when placing
content of X-Content-Security-Policy into X-WebKit-CSP?

----------------------------------------------------------------------

Comment By: wdauchy (wdauchy)
Date: 2012-05-16 08:06

Message:
I applied commit 4a141a0
(https://github.com/phpmyadmin/phpmyadmin/commit/4a141a067c6b0a04e512ad73dcd86bbd188fa0ab)
on top of a 3.5.1 release but it does not seem to fix the problem. Am I
missing another commit?

----------------------------------------------------------------------

Comment By: Michal Čihař (nijel)
Date: 2012-05-15 05:20

Message:
This bug was fixed in repository and will be part of a future release;
thanks for reporting.

----------------------------------------------------------------------

Comment By: Rouslan Placella (roccivic)
Date: 2012-05-14 08:28

Message:
Quoting brightbeat:

An easy fix currently for content-security-policy can be to add this line
to config.inc.php
$cfg['AllowThirdPartyFraming'] = true;

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377408&aid=3523499&group_id=23067

Bugs item #3527562, was opened at 2012-05-17 03:53
Message generated for change (Settings changed) made by nijel
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377408&aid=3527562&group_id=23067

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Internationalization
Group: 3.5.1
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ciprian Marinescu (braila)
>Assigned to: Michal Čihař (nijel)
Summary: $GLOBALS['text_dir'] wrong value for Romanian

Initial Comment:
If language is Romanian, $GLOBALS['text_dir'] is nor ltr nor rtl. The value of $GLOBALS['text_dir'] is something like ssd (after executing index.php).
Navigation frame is never displayed and objects' displaying order is sometimes ltr and other times rtl - very annoying.
I previously used 3.4.x version and the bug appeared in 3.5.1 version.

System : Windows XP SP 3 / Apache 2.2 / PHP 5.3.6 / MySQL 5.5.13

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377408&aid=3527562&group_id=23067

Bugs item #3527531, was opened at 2012-05-17 02:11
Message generated for change (Settings changed) made by lem9
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377408&aid=3527531&group_id=23067

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Interface
Group: 3.5.1
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jan Pecek (janpecek)
>Assigned to: Marc Delisle (lem9)
Summary: GC-maxlifetime warning incorrectly displayed in 3.5.1

Initial Comment:
Using $cfg['LoginCookieValidity'] greater than session.gc-maxlifetime the warning is shown.

With PMA 3.5.1, the warning is not rendered correctly (as HTML with a clickable link to the documentation), but sanitized which results in escaped HTML entities instead of HTML (like "Your PHP parameter <a href="./url.php?url=http%3A%2F%2Fphp.net..."), similar to ID: 3519747

In dev (last from github, rev. 12af3d2) version it's ok. I'm expecting the next version will be correct.




----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377408&aid=3527531&group_id=23067

Bugs item #3527531, was opened at 2012-05-17 02:11
Message generated for change (Comment added) made by lem9
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377408&aid=3527531&group_id=23067

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Interface
Group: 3.5.1
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jan Pecek (janpecek)
>Assigned to: Nobody/Anonymous (nobody)
Summary: GC-maxlifetime warning incorrectly displayed in 3.5.1

Initial Comment:
Using $cfg['LoginCookieValidity'] greater than session.gc-maxlifetime the warning is shown.

With PMA 3.5.1, the warning is not rendered correctly (as HTML with a clickable link to the documentation), but sanitized which results in escaped HTML entities instead of HTML (like "Your PHP parameter <a href="./url.php?url=http%3A%2F%2Fphp.net..."), similar to ID: 3519747

In dev (last from github, rev. 12af3d2) version it's ok. I'm expecting the next version will be correct.




----------------------------------------------------------------------

>Comment By: Marc Delisle (lem9)
Date: 2012-05-17 03:27

Message:
In current dev version, the rendering may be ok but the link does not work.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377408&aid=3527531&group_id=23067

Bugs item #3526916, was opened at 2012-05-15 05:53
Message generated for change (Settings changed) made by alsbz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377408&aid=3526916&group_id=23067

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Interface
>Group: 3.5.1
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Arashi (alsbz)
Assigned to: Nobody/Anonymous (nobody)
Summary: "Search in table" page fails with JS error when tooltips dis

Initial Comment:
"Search in table" page fails with JS error when tooltips disabled. 
All browsers.
I see JS errors in browser console instead of search results when disabled tooltips in my current user preferences.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377408&aid=3526916&group_id=23067