Danbooru 2 Issues Topic

Just tried to fix note display in post #1464963 to put black text on white background, and the <span> tag isn't working. The display essentially ignores the entire tag.

I thought I might be mistyping something, even though it all looked right, so I went to check some of my previous notes using <span> and <div>. The couple of examples I looked at had lost all effects from those tags, and clicking to edit showed that all formatting within the tags is now gone. (E.g., if a tag originally had "<span style ="font-size:400%; color:white; background-color:black>", it now just reads "<span>".

Now, I'd seen similar lack of tag content display when we were originally making the transition to 2.0, but at least that was a cause I was aware of. Before I panic or get upset, how much concern should this actually be worth?

Probably a side effect of change in sanitize version used, in this commit, causing HTML that was allowed before (i.e. style attribute) getting removed. I don't grok ruby, but cursory a look suggests that changes in Sanitize API in ver 3.0.0 (Sanitize.clean renamed to Sanitize.fragment, etc) may be the cause.

As far as I can tell, sanitization occurs during display (including previewing edits); note formatting is still saved correctly to the database, as per your recent test. Formatting from older edits made also still show correctly in the note history, so I don't think anything got lost here, Danbooru code just needs updated to work with new sanitize API.

Moonspeaker said:

Just tried to fix note display in post #1464963 to put black text on white background, and the <span> tag isn't working. The display essentially ignores the entire tag.

The sanitizer was removing all css. Fixed for the next version.

r0d3n7z said:

As far as I can tell, sanitization occurs during display (including previewing edits); note formatting is still saved correctly to the database, as per your recent test. Formatting from older edits made also still show correctly in the note history, so I don't think anything got lost here, Danbooru code just needs updated to work with new sanitize API.

Half true. Currently, if you add css to a note and save it it will get saved to the database and just get displayed wrong. So nothing gets lost in this case.

But if you go to edit a note that already had css before you got there the edit window will display the sanitized version for you to edit, without css. If you click Save on this (even without editing anything) then the version with no css gets saved to the database so stuff gets lost.

Toks said:

But if you go to edit a note that already had css before you got there the edit window will display the sanitized version for you to edit, without css. If you click Save on this (even without editing anything) then the version with no css gets saved to the database so stuff gets lost.

Yes, I think both Moonspeaker and myself were aware of this, since we did experiment / try to fix notes. What I meant was, if you included formatting in a note -- as he did in the example I gave -- it would save properly even if the preview (and subsequently, display) doesn't work.

Anyhow, thanks for your very prompt fix

r0d3n7z said:

Anyhow, thanks for your very prompt fix

What he said!

how bout the shortcut "Q" search ? it's not working on the google chrome latest version [v41]
i forced to use previous version because this bug ):

r0d3n7z said:

Probably a side effect of change in sanitize version used, in this commit, causing HTML that was allowed before (i.e. style attribute) getting removed. I don't grok ruby, but cursory a look suggests that changes in Sanitize API in ver 3.0.0 (Sanitize.clean renamed to Sanitize.fragment, etc) may be the cause.

As far as I can tell, sanitization occurs during display (including previewing edits); note formatting is still saved correctly to the database, as per your recent test. Formatting from older edits made also still show correctly in the note history, so I don't think anything got lost here, Danbooru code just needs updated to work with new sanitize API.

The problem still seems to exist for webkit formatting, which I was given to understand requires redundant format text in order to work in different browsers.

I couldn't remember the exact syntax, so I went to post #1756820 to check. The entire formatting is in the Notes history as <p style="-webkit-transform: rotateY(180deg); -moz-transform: rotateY(180deg); -ms-transform: rotateY(180deg); -o-transform: rotateY(180deg); transform: rotateY(180deg);"> but all that shows when I click to edit the note is <p style="-webkit-transform: rotateY(180deg); transform: rotateY(180deg);"> Mind you, the note still displays properly reversed text for me, so I don't know how necessary a fix this might be.

Moonspeaker said:

The problem still seems to exist for webkit formatting, which I was given to understand requires redundant format text in order to work in different browsers.

I couldn't remember the exact syntax, so I went to post #1756820 to check. The entire formatting is in the Notes history as

<p style="-webkit-transform: rotateY(180deg); -moz-transform: rotateY(180deg); -ms-transform: rotateY(180deg); -o-transform: rotateY(180deg); transform: rotateY(180deg);">

but all that shows when I click to edit the note is

<p style="-webkit-transform: rotateY(180deg);    transform: rotateY(180deg);">

Mind you, the note still displays properly reversed text for me, so I don't know how necessary a fix this might be.

I don't think it's possible to restore the old behavior where all css is allowed, so instead what I did to fix it was allow css listed in the relaxed Sanitize config (has about 400 of the more common css properties listed).

I could manually add more if something important is missing.

I believe -moz-transform -ms-transform and -o-transform used to be necessary for old browsers but now they're obsolete and just -webkit-transform and transform are necessary.

Can't seem to find artists anymore with a direct link from Pixiv?

Toks said:
I believe -moz-transform -ms-transform and -o-transform used to be necessary for old browsers but now they're obsolete and just -webkit-transform and transform are necessary.

Ah, okay. That's encouraging.

Any update on the possibility of adding Vote Up and Vote Down hotkeys? Never got a response about that. (Especially with the Vote Up being the same as Pixiv, "L")

Can someone delete the fake flags from post #133181 and post #140982? They are originating from the security breach quite some time ago, I just noticed they are still there.

Schrobby said:

Can someone delete the fake flags from post #133181 and post #140982? They are originating from the security breach quite some time ago, I just noticed they are still there.

PM Albert

I'm not sure if this is a bug or a new feature but I've noticed on some pages the notes become effectively hard translation but on others they stay as the usual hover over to view type notes

An example of the odd ones post #840398 and the standard type post #1627350 I'm just unsure if I missed something new or I found a bug

Zelinkokitsune said:

I'm not sure if this is a bug or a new feature but I've noticed on some pages the notes become effectively hard translation but on others they stay as the usual hover over to view type notes

An example of the odd ones post #840398 and the standard type post #1627350 I'm just unsure if I missed something new or I found a bug

It's a new feature. See topic #11337.

I'm not sure if this is the right place, but I'm getting

ERROR: canceling statement due to statement timeout

messages. From a search I see I'm not the only one.

MaxAndEmilytate said:

I'm not sure if this is the right place, but I'm getting messages. From a search I see I'm not the only one.

Where are you getting those messages though?

Toks said:

Where are you getting those messages though?

Weird. I can't seem to reproduce it right now. Should have screenshot'd. One of the error messages appeared when I was doing a search for "panties_around_one_leg rating:s" at page 5.

MaxAndEmilytate said:

Weird. I can't seem to reproduce it right now. Should have screenshot'd. One of the error messages appeared when I was doing a search for "panties_around_one_leg rating:s" at page 5.

When you combine two tags that individually have large post counts into a search that has a small post count it can be slow. rating:s has tons of posts and panties_around_one_leg has a fairly large number too, but panties_around_one_leg rating:s only has a handful.

As for why it's not happening now when it was before, maybe you were trying it while the site was under relatively heavy load. I think subscriptions were in the middle of being processed around the time of day you originally said you were having the problem.