Report site bugs here

@liamwhite1  
Here is for Firefox, here is for TOR Browser. I can also send log in HAR format in PM.

Given the following:
 

 
If the image being referenced contains a tag you have spoilered/filtered, the result is that the spoiler image is visible through the overlay, and the text is slightly visible:
 

EDIT: Addressed.
 
There doesn’t seem to be any other word of this on the thread; if the issue has already been addressed and I’m just blind, please let me know.
 
There is a bug I’ve encountered a few times recently with which images related to a tag you have hidden can still be seen as though spoiler’d. It usually seems to occur when an image you uploaded, and sometimes one you’ve commented on, is later given a tag that you have hidden. I first found this out when adding the “image macro” tag to an image I posted; I had never viewed image macro (which is hidden by default) prior to this, and after posting the image, when I viewed my uploads it appeared with the spoiler for image macro. Upon opening the page, it even gave me the “spoilered by your current filter” message; except it said “hidden by your current filter,” instead.
 
This has since happened with a couple of images I did not upload myself, with other tags I had hidden. One example: I had already commented on this image, having found it during normal browsing. After I had already viewed it, someone added the “rape” tag, (which has since been removed, and) which was also hidden by default as I’d never previously attempted to view anything with this tag. Though I still had this tag completely hidden at first after it was applied to the image in question, upon navigating back to this image through my notifications it pulled up the page in the same way it would if the tag were under spoiler, except the message read “hidden by your current filter.”
 
Is this an intentional fallback mechanism in attempt to maintain the integrity of one’s filters? If so, I think the task would be better completed with a message explaining that the image can no longer be viewed under the current filter, and which tag is causing this. If not, this is a bug that some users might prefer to be addressed.

@Ren  
There are very few pages (but they do exist!) where the server-side filtering system does not work completely, or not at all.
 
Filtering is handled completely by our search engine, and if we bypass the search engine and load things directly from the database, there is no way to prevent it from appearing in listings. One example is the notifications page, which you mentioned.
 
In this case, even though the image is supposed to be hidden, the scripts running on the page run the spoiler code to prevent you from seeing the image, but don’t remove it from the listing.

@liamwhite1  
Ah, I see. Well, I trust you guys would’ve figured out a work-around if you feasibly could’ve. Thank you for explaining this! ^_^

Hey, I don’t know if it’s a bug or something.  
Did any of you get sent to a page where you have to verify yourself that you are not a spam bot?

@SeraphimDawn
 
That’s a common security thing for logins on a lot of websites, but it usually doesn’t take you to another page…

@SeraphimDawn  
You really need to give us more info here. Cloudflare does have an anti-bot/ddos thing if you’re coming from a proxy or recently flagged address.

@The Smiling Pony  
I’m not using a proxy.  
But I suspect I bumped into that said anti-bot/ddos mechanism you described.

First part: initial view
 
Second part: after clicking ‘@Princess Celestia’. Note the lack of a space after each period.
 
Third part: after clicking ‘@Princess Celestia’ again. The space between comments has increased.
 

@iloveportalz0r  
Known bug, I’d almost forgotten about it. Just need to rewrite comment anchoring a little.
 
EDIT:fixed, not yet deployed.

My gut says this is CloudFlare’s problem, but apparently they only provide support to customers (you), so if this is indeed a CDN problem you may have to escalate to their support.
 
My HTTP connections to derpicdn frequently drop, usually when long responses are involved. If SPDY/HTTP2 is enabled, the problem is exacerbated because, AFAICT, the entire session and all in-flight requests are aborted. This manifests as missing thumbs or partially loaded images.
 
Is the server or the CDN configured to abort slow transfers? Unfortunately, I only have 768kbps, and loading a full-size image or two while browsing thumbs can result in a lot of parallel requests. AFAICT, the browser parallelizes the requests for all thumbs of a result page.
 
Disabling SPDY improves things quite a bit. Perhaps because parallelism is reduced, so requests are completed more quickly. Perhaps because only one request is lost if the server aborts a connection, because requests do not share connections.
 
I’m also puzzled by some images starting to load uninterlaced, getting interrupted, and upon attempt to continue loading them (right click -> view image) getting a “corrupted content” error. On reload, they load as interlaced images.
 
Mozilla/5.0 (X11; Linux x86_64; rv:46.0) Gecko/20100101 Firefox/46.0
 
Out of curiosity, how does the H2 setup work, anyway? Does the CDN handle it all and your server only sees a bunch of (persistent) HTTP 1.1 connections?

@heftig  
Clover will have to respond on the first part; anything I could contribute would be merely speculation because I don’t know.
 

We don’t serve any interlaced images. This is CloudFlare (unlikely) or your user agent’s (likely) doing.
 

There shouldn’t be any issue with long-running connections - our connection timeouts are quite conservative, as are our next-byte timeouts. So long as you transfer some data every 10 seconds, nothing bad will happen, and your connection would have to be properly fucked for that to be the case. You can keep a request going for quite a long time (an example of this is uploads, which can take minutes thanks to the fact most people have asymmetrical internet with crap upload speeds well below 1Mbps).
 
As for how your client handles dropped/failing h2c requests, that’s up to your client - I’m not sure it’s defined in an RFC.

@Clover the Clever  
I guess this is the problem, then: Firefox defaults to allowing 100 concurrent requests over SPDY/H2. If even one of these requests is not handled by the CDN cache, creates a real connection to your server and CF cannot multiplex all the responses finely and fairly enough, it could time out.
 
I’ve also seen head-of-line blocking when SPDY/H2 is enabled (one big image loading prevents thumbs from doing so), so poor multiplexing triggered by my poor download speed seems likely to me. HOL blocking has been getting better, lately, though.
 
 
@liamwhite1  
My user agent? Huh? The only proxy between you and me is the CF CDN. I believe the first load didn’t hit their cache and loaded the uninterlaced image from your server. Afterwards, resuming issues a Range request, but this now hits a re-encoded image in the CDN cache, and the different data causes image decoding to fail.
 
Those uninterlaced transfers are also ones prone to getting interrupted, so if they’re the ones creating real connections to your server then your timeouts seem to be the problem, indeed.
 

 
Could you please forward these problems to CF? At the very least they’ll tell you it’s not their problem.

@heftig  
If you could dump some HARs showing this, and run a few speedtest.net tests, and save one or two of these corrupt files, and forward the results to clovertheclever at derpibooru.org via email that’d be very helpful. We do proactively take up issues with CF support where we can determine it’s a fault in their side.

The “theme-color” meta tag has the same hex code set regardless of if you’re on the light theme or the dark theme, so when viewing the site on a mobile device with the dark theme selected, you get a light blue browser bar instead.

@Blossomforth  
That is a 1-minute hack that I didn’t even commit, just patched to see how it would work.
 
Is there a color that works for both themes?

@liamwhite1
 
The only thing I could think of is either grey, or a darker shade of blue (since the navigation menu on both themes is blue)
 
It seems that 618FC3 is about the middle point between the color of the nav bar on the light and dark themes, not sure how that would look though

@Blossomforth  
Use 00FFFF and let’s get some eyeballs bleedin’.
 
…36465D is a medium-dark blue that looks good against both light and dark.

@TexasUberAlles  
That’s not bad. What I did was just take the color of the navigation menu from both the light and dark theme (they’re different, but not too dissimilar), created a gradient between the two, and picked the color from the middle of the gradient, which is essentially the “average” of the two colors.
 
If you look closely, you can tell it’s different, but it looks similar enough that I don’t think too many people would notice.

>this new color  
Reeee bleeding eyes etc.  
Excuse me while i mop up my blood.

Every other post just gained a light purple background. Like, just now.

@YetAnotherBrony  
Fixed.

@liamwhite1
 
That was weird.
 
I kinda liked it, though.