On Tue, Jul 24, 2012 at 11:06 PM, Marc Delisle marc@infomarc.info wrote:

Ok, please post here when it's integrated.

The ExportSql and ExportMediawiki plug-ins are usable now on my branch and can be merged, but I still haven't solved the custom options bug.

-- Alex

On Wed, Jul 25, 2012 at 2:18 PM, Alex Marin alex.ukf@gmail.com wrote:

I still haven't solved the custom options bug.

I've done a git bisect in order to see when the bug I was talking about was introduced, but I could only find a range of commits. The last commit that I can see that does not contain the bug is 0941d2c, and the first one that I can say for sure it does is a14da7b. Between those two, is a range of 12 commits: 4a74037 .. afb5600, where I cannot see if the bug is present or not, because the export page is not displayed at all.

The behavior of the bug is as follows: When trying to export a table or a database, the Export Method div (#quick_or_custom) does not have a style="display: block" , so it is hidden from the css and you cannot select the export method. Additionally, all of the format specific options for all of the export plug-ins are displayed on the same page.

I can't really seem to figure out why the toggle_quick_or_custom() function in export.js is not triggered. That seems to be responsible for the hide/show differences, so fixing that may remove the behavior of the bug.

Rouslan, I saw that the range of commits that prevent me from seeing the export page are related to introducing the PMA_Header class. I don't know if this has anything to do with the bug, or if it is something done earlier that popped up then, but if you have any wild ideas about what could be wrong, please share :)

-- Alex

On 13/08/2012 16:09, Alex Marin wrote:

Rouslan, I have a quick question:

For exporting a database, in db_export.php there is this code:

$response = PMA_Response::getInstance(); $header = $response->getHeader(); $scripts = $header->getScripts(); $scripts->addFile('export.js'); [..]

And in js/export.js, the functions are called with the .ready() handler. F.e.: $(function() { toggle_save_to_file(); $("input[type='radio'][name='output_format']").change(toggle_save_to_file); });

I've noticed that none of the functions in js/export.js are triggered and deleting the whole content of the file actually leads to the same behavior of db_export.php (or tbl_export.php or server_export.php). But if you insert an alert without the $(function() {}); handler, it will pop-up. Is it possible that this is related to the way the script is included via the addFile() method in the PMA_Scripts class?

No, nothing to do with the PMA_Scripts class. BTW, in current master for me all of the document-ready handlers are triggered correctly on all export pages (putting in an `alert(1)` shows a popup as expected). Tested in Firefox 14.0.1 and Chrome 18.0

Bye, Rouslan

On 16/08/2012 15:57, Alex Marin wrote:

Ok, this is one of the weirdest bugs I've seen.

If you insert an alert(1), indeed it works, but if you put a $(function() { alert(1); } it doesn't pop up, which means the page isn't fully loaded. So, if you try an alert(document.readyState); it will show you "loading", which means something prevents the page from being fully loaded. The errors shown in the chrome console are:

4Unrecognized Content-Security-Policy directive 'allow' 4Unrecognized Content-Security-Policy directive 'options' 2Uncaught SyntaxError: Unexpected token ILLEGAL (get_image.js.php:239) Uncaught ReferenceError: PMA_getImage is not defined (functions.js:3033)

The first 2 types of errors are related to my chrome version I think (20.0), the illegal characters are some weird � after the last line of code and PMA_getImage() was used before in functions.js, but the first error occurs only at line 3033. The most accessible error seemed to be the one with illegal characters, so I put a comment on the last line, hoping to ignore that unknown string, but with no success.

Taking a look in the get_image.js.php file, I saw that there is a mix of js and php, and, at the end, the js function PMA_getImage() is declared outside of <?php ?> tags. This file is included in the PMA_Header class with: $this->_scripts->addFile( 'get_image.js.php?theme=' . urlencode($_SESSION['PMA_Theme']->getId()) ); Then I noticed that $_SESSION['PMA_Theme']->getPath() was used in get_image.js.php and I remembered that Michal said something earlier about an error with getPath(), so I removed that, but with no success. At this point I was already delusional, so I figured if I remove the theme=PMAHomme variable from the url, maybe I'll avoid something evil. Most shockingly, this worked. But when I wanted to commit, I deleted the comment at the end of get_image.js.php, and the js functions did not trigger again.

This doesn't make much sense to me anymore, but turns out a solution is a combo of commenting the last empty line in get_image.js.php and removing the "theme" GET variable, which I did here [0]. I think there are more rational ways of getting rid of those unknown chars, but I did not manage to find any.

PS: I wouldn't have mistakenly reached this without the already famous rubber duck debugging technique [1].

[0] https://github.com/alexukf/phpmyadmin/commit/6867d605aeb63ddd55e31f18b665d7d... [1] http://en.wikipedia.org/wiki/Rubber_duck_debugging

For me chromium 18 only throws the CSP errors...

I don't see anything weird at the end of get_image.js.php. In your commit, you have one addition and no deletions for that file, so your not commenting anything out, you're just adding a comment. Perhaps you could try to simply add a newline character at the end of the file?

The "theme=someid" parameter is necessary and must not be removed. The idea there is that different themes have different icons embedded in the sprite and that js file is cached on the client side. So the theme id is necessary to invalidate the cache when a user switches themes.

Bye, Rouslan

On 16/08/2012 22:21, Alex Marin wrote:

On Thu, Aug 16, 2012 at 10:17 PM, Rouslan Placella rouslan@placella.com wrote:

...

I don't see anything weird at the end of get_image.js.php. In your commit, you have one addition and no deletions for that file, so your not commenting anything out, you're just adding a comment. Perhaps you could try to simply add a newline character at the end of the file?

Yes, I'm adding a comment for the unknown characters that are somehow appended at the end of the file.

But there aren't any characters there... Look at it with a hex editor if you want to, but there is nothing on the last line. Besides, if there was a character there, your commit would show a deletion, but it only shows an addition.

...

The "theme=someid" parameter is necessary and must not be removed. The idea there is that different themes have different icons embedded in the sprite and that js file is cached on the client side. So the theme id is necessary to invalidate the cache when a user switches themes.

Ok, I've put that back where it belonged and it seems to work fine now in my tree.

-- Alex

On 16/08/2012 23:27, Alex Marin wrote:

On Thu, Aug 16, 2012 at 11:25 PM, Rouslan Placella rouslan@placella.com wrote:

...

But there aren't any characters there... Look at it with a hex editor if you want to, but there is nothing on the last line. Besides, if there was a character there, your commit would show a deletion, but it only shows an addition.

No, I never said that those characters are in the file. But somehow, when that file is included, some weird characters are produced, or at least that's what my browsers tell me. I introduced an empty comment with the hope that it will actually be applied to anything that is appended immediately after, which it did. As I've said, it doesn't make much sense :) Or probably it does, but I did not find an explanation yet for where do those unknown characters appear from.

Ok, I see.