I've not been able to reproduce what you describe. If you have more explicit list of things we can do to reproduce, it could help. scrolling has changed recently do anything is possible.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Feb 3 2015
It's not, because this only stopped to work recently and scrollbar is showing fine on any other Phabricator page. For example this task detail page: http://screencast.com/t/b0bTUm41s
I have like 3/4ths of a diff to swap us to D3.js which I think I'm going to try to sneak in here, maybe. The actual fix for this is probably trivial, but it would be nice to spend a little more time and get and extra result out of it since I have to test it anyway.
Is this a "Magic Trackpad" issue? That is, do you see it fine with a normal trackpad or mouse?
I think this is probably worth hiding if empty, although it also probably won't be empty forever.
Tickets! oh boy!
New Instance, New Support Ticket, etc. There should be things that end up there. Will let Evan decide.
I just noticed it on phacility, you could probably get the same affect by changing the policy on all applications to require users be in a certain group.
Like everyone at a company can login and view, but only those in a specific group can do anything.
Can you explain more about how you're using Phabricator?
Looks like its not JS related, disabled JS and the issue persisted, disabled CSS, works.
Feb 2 2015
A simple way to compare scroll distance is to open multiple browsers, scroll all the way to the top and scroll the mousewheel down one notch. Chrome on Windows puts me halfway through the task's title, while Firefox barely escapes the top bar.
Oh, right - my mistake - So, here I am on windows machine with firefox, IE & chrome opened on this task. Versions are super recent (installed 10 mins ago)
The "half-speed scroll" is specific to Windows.
This is weird. I work almost exclusively in firefox and I experience none of said problems. Phabricator scrolling is OK. That can be also compared between phabricator instances running pre-fake-scrollbar revision. So... it feels completely OK for me under Firefox 35 and GTK (linux)
In T7109#94036, @epriestley wrote:I think the issue is that we're technically scrolling a frame, not the document root.
You are right - if I remove the 'overflow: hidden' and 'overflow-y: scroll' styles scrolling is fast as ever! I cannot find any reason on why Firefox would reduce the scrolling speed for a single frame.
My initial thought is that Firefox's behavior here is completely bananas.
I think the issue is that we're technically scrolling a frame, not the document root. It looks like Firefox scrolls frames at 50% of the speed that it scrolls the document root:
In T7109#94031, @epriestley wrote:You can keep the natvie scrollbar on screen by commenting out this line:
You can disable the non-native scrollbar completely by adding return; here:
I tested Win/Ubuntu/Mac with Scrollbar changes on, off, and the patch, and I could not perceive any regression. One mouse scroll got me to the same place each time. The only thing that improved scrolling for me in any version of Firefox was changing the about:config options in Firefox itself.
In T7109#94027, @epriestley wrote:@GMTA, do you have an older machine or a netbook or something like that?
It feels like a distance traveled per scroll. On github I get maybe 500px for a scroll, on phabricator maybe 100-200.
You can keep the natvie scrollbar on screen by commenting out this line:
D11622 might fix this, if it's related to redraw performance. Can you try applying that and see if it resolves things?
Yeah, Firefox doesn't feel quite like native scrolling to me, but it feels the same on Phabricator / Hacker News / Reddit. Definitely not 3x slower in Phabricator than on other sites.
I'm seeing a huge difference in scroll speed between Phabricator and other sites, and I'm 99% sure that scrolling is slower since the introduction of the new scrollbar. Is there a way for me to temporarily use native scrolling (through the console?) to confirm this?
Actually Firefox scrolling is slow for me on every website, not just Phabricator.
Can I test it not being offscreen for performance?
Dunno if this profile helps.
Odd. We aren't doing anything which should affect this (that is, we don't intercept mousewheel events or anything, and the frame still has a normal scrollbar, it's just hidden off to the side of the screen). Seems unchanged on, uh, whatever the one before Yosemite is. Cougarlion or whatever.
Vertical scrolling seems about 3x faster using the native scrollbar in Firefox based on visual guesstimations.
It has this strange latency, running 35.0.1 Mac/Yosemite.
Hmm, feels pretty normal to me.
Yeah it's craptastic on Mac too.
@chad, can you reproduce this?
And on an unrelated note: personally I don't think T7014 was worth replacing the native scrollbar with a fake one throughout Phabricator. There have been exactly zero convincing, bug-free, user friendly fake scrollbars on the internet up until now, why is this one going to be different? :)
This is also an issue on Firefox/Windows.
This issue is also present in Firefox.
hardcore man
haha, that's the one I thought would be out there but I couldn't find a repro. Though I also have lots of setup issues.
Jan 29 2015
Jan 28 2015
We are likely to move Conpherence to Source Sans as well, so shoring up any issues will be important.
@chad
Thanks for adding latin extended font. And my firefox supports woff2 already (I use this version).
And the font rendering issue is only reproducible on my laptop, currenty I work on my normal computer and phirction looks fine. My laptop has Windows 8.1 x64 Polish version. Perhaps the issue is triggered by language settings. Anyway I hope updated woff2 fonts to solve the issue. Currently I use this fonts on my local instance (woff, not woff2):
http://fonts.googleapis.com/css?family=Source+Sans+Pro:400,700&subset=latin,latin-ext
Also the issue is not reproducible on IE.
In T7066#93472, @chad wrote:Firefox doesn't officially support woff2 (http://caniuse.com/#feat=woff2) but this is a step to supporting more languages on some browsers. I'll continue to look into building more support (we really like Source Sans).
In T7066#93467, @chad wrote:Latin Extended according to Adobe:
Welsh, archaic Danish and Esperanto.
Firefox doesn't officially support woff2 (http://caniuse.com/#feat=woff2) but this is a step to supporting more languages on some browsers. I'll continue to look into building more support (we really like Source Sans).
You can see if D11545 renders any better or not, not sure I see a difference.
Latin Extended according to Adobe:
Well, mine install + This one looks ok. On firefox at least.
I built a version of "everything" Source Sans as a woff2 file in my sandbox, I just can't seem to find a place where it actually fixes anything. I did something similar to my local sandbox like you're Phriction document.
Hey @chad - Latin Extended would be useful for anybody in central/eastern europe. It does make font bigger, but some DO need it (and it may look horrible without it). My install also looks fine, so maybe I simply have good set of fonts already present on my system and Firefox selects proper ones?
I'm not able to find a reproducible case here, I tested current Firefox (35) in Mac, Windows, and Linux:
If you could provide a testable Phriction document on this install, that would be very helpful.
Jan 27 2015
Well, this is kind of involved.
I'm fixing this but it's 98% navigating Adobe's breathtakingly functional site.
So - The problem is present in Webkit based browsers, because all mine Gecko
based are working fine.
Actually, I have same issue.
But in my case, I use mobile chrome browser. In mobile chrome browser, the Diff section is not react my finger touch.
(I use android KK, and latest chrome browser)
I can't confirm. Differential scrolling (and general scrolling) works fine for me under Firefox 35 here and on local install.