在用户讨论:Arumi的话题

大佬好,

   我看了下Wiki的介绍发现技术面的问题是由阁下所负责,
   我有一些bug(?)想要提交或者说改善要望(笑), 希望有找对人.

・由于未在其他设备上进行过测试, 本人并不确定以下所提交的bug是否可以在其他设备上如期重现.

     本人所使用的环境如下
         Windows 10 Pro v1903 18362.10019
         Google Chrome v77.0.3865.75 64bit

・bug反馈

　　　1.東方原曲页面 - 二次同人数据项下所引用数据相关

　　　　　　问题表象：同人曲目数量(每半年)图表描绘时间轴中断 具体可参照 献给已逝公主的七重奏词条

                     时间轴从2015H2开始中断, 并未描绘出后续数据
                     通过查询 同人专辑搜索 可得知 2015H2 - 2019H2 期间仍有其同人曲目产出
                     故得出结论 - 图表描绘不完整 (即使0数据也理应被描绘出来)

           问题重现：东方红魔乡 同一时期的原曲
                     U.N.OWEN就是她吗？ 同样存在上述问题
                     魔法少女们的百年祭 却没有出现上述问题

           问题研判：目前所发现的个例出现在较早期的作品中 并且都是同人化程度很高的曲子
                     由于出现问题的时间节点2015H2的数据下滑有些异常, 我求了一下和, 发现了问题之所在(可能的)
                     即当历年同人曲目数量之和达到或超过2000的情形下, 该图表会出现上述问题.
                     (献给已逝公主的七重奏 - 总数 2859)
                     (U.N.OWEN就是她吗？   - 总数 3087)(貌似计数模块正常工作)
                     (魔法少女们的百年祭   - 总数  703)

                     由于采用的应该是模板, 故推测该现象会在同人化高的曲子页面普遍存在, 亦或随着时间的推移逐渐显现.
                     因会对该项功能造成一定影响, 还请大佬修正.

           潜在问题：受上述问题的影响, 制作方图表数据是否会受到牵连
                     即当历年同人曲目数量之和达到或超过2000之后, 制作方图表的计数是否正常统计? 也请大佬酌情加以调查.

设计当初没有预想到会有超过2000首同人曲的情况，导致只能统计最早2000首同人曲，现在已经把上限提高到5000

感谢回复, 膜拜下大佬的神速修复. 闲话不多说, 下面进入改善要望部分.

・改善要望

　　　1.页面 div id：siteNotice 项下 div id：scrollDiv JS滚动事件相关

　　　　　　问题表象：打开本站任意页面后, scrollDiv的JS滚动事件运作正常(setInterval=5000)
　　　　　　　　　　　一旦切换至其他标签页并经过一段时间后, 在返回前述标签页之时发生JS滚动事件异常加速的现象
　　　　　　　　　　　鸡血速度滚动(目测间隔0.5秒左右), 一段不定时间后恢复正常5秒间隔.

　　　　　　问题重现：本人使用的是Chrome浏览器, 并未测试在其他环境是否会发生同样状况.

　　　　　　问题研判：Google从2017年Q2开始对非活跃页面的后台计时器进行限制, 以节省内存并改进电池使用寿命. 参见 长期愿景和未来计划
　　　　　　　　　　　受此影响, 当切换到其他页面并且问题页面进入非活跃状态后, 页面定时器不运动但是动画依然排列.
　　　　　　　　　　　所以当切换回来时就出现了上述鸡血滚动的现象(个人猜测).

　　　　　　　　　　　页面当初的设计并无问题, 但受外部政策影响才出现了上述计时器异常.
　　　　　　　　　　　推测影响范围为本站全体页面, 桌面移动双端, 通过Chrome或使用Chromium内核的浏览器访问.

　　　　　　　　　　　最后, 本计时器异常并不会造成多大影响, 本人在此姑且提出改善要望.
　　　　　　　　　　　是否需要修复还请大佬酌情进行判断, 在此再次对阁下的辛勤付出表示感谢.