https://developers.weixin.qq.com/blogdetail?action=get_post_info&docid=00020a9149c35007a3d6aaa1c51800&highline=arrowLine https://developers.weixin.qq.com/blogdetail?action=get_post_info&docid=000cee90c089f88101d68ba525e400&highline=arrowLine 请问线上的bug，真的没人关注吗？

android没有异常，iOS的整个map组件arrowLine失效。我们用这个做关键指向在山里导航，人命关天，盼复。

代码非常短，代码片段已经提供。 js [代码]const app = getApp()[代码][代码]Page({[代码][代码]  [代码][代码]data: {[代码][代码]    [代码][代码]datedisplay:[代码][代码]""[代码][代码],[代码][代码]  [代码][代码]},[代码][代码]  [代码][代码]onLoad: [代码][代码]function[代码] [代码]() {[代码][代码]    [代码][代码]let d = [代码][代码]new[代码] [代码]Date()[代码][代码]    [代码][代码]this[代码][代码].setData({date:d})[代码][代码]    [代码][代码]this[代码][代码].setData({datedisplay:d.toLocaleString()})[代码][代码]  [代码][代码]},[代码][代码]})[代码] wxml [代码]<[代码][代码]wxs[代码] [代码]module[代码][代码]=[代码][代码]"util"[代码][代码]>[代码][代码]  [代码][代码]function toLocal(time) {[代码][代码]    [代码][代码]d = getDate(time)[代码][代码]    [代码][代码]if (d == "Invalid Date") return ""[代码][代码]    [代码][代码]return d.toLocaleString()[代码][代码]  [代码][代码]}[代码][代码]  [代码][代码]module.exports.toLocal = toLocal[代码][代码]</[代码][代码]wxs[代码][代码]>[代码] [代码]<[代码][代码]view[代码] [代码]class[代码][代码]=[代码][代码]"intro"[代码][代码]><[代码][代码]text[代码][代码]>[代码][代码]JS toLocaleString:[代码][代码]{{datedisplay}}[代码][代码]</[代码][代码]text[代码][代码]>[代码][代码]</[代码][代码]view[代码][代码]>[代码] [代码]<[代码][代码]view[代码] [代码]class[代码][代码]=[代码][代码]"intro"[代码][代码]>[代码][代码]<[代码][代码]text[代码][代码]>[代码][代码]WXS toLocaleString:[代码][代码]{{util.toLocal(date)}}[代码][代码]</[代码][代码]text[代码][代码]></[代码][代码]view[代码][代码]>[代码] 做的事情也非常简单，对比js部分的Date.toLocaleString() 和wxs部分Date.toLocaleString() 安卓下截图： [图片] iOS截图 [图片] BUG显而易见。很显然在安卓里，js框架内的Date对象toLocaleString()被简单地作为toString()处理了，其他toLocaleTimeString(), toLocaleDateString()都存在问题。这个问题非常久了，希望赶紧处理。这都是小程序框架基础函数级别的服务，有这种问题那么久没发现也是一个奇迹。

我们之前做过测试，没有碰到过安卓手机wx.request 的url不做encode的，所以也没有做任何处理，一直安然无恙跑了半年。 本周突然有大量安卓手机但不是全部反馈无法正常使用（机型如vivo x7，最新微信版本和库），最终确认是没有统一做encode。请问是不是有改动？ 补充下： 在2016年12月22日的更新日志里，对于基础库更新有以下内容： 更新日志 0.11.122100 [代码]F[代码] 修复 [代码]wx.request[代码] 没有对请求数据正确 encode 的问题 所以我们是否可以认为wx.request内的确是会对请求做这个encode？

- 当前 Bug 的表现（可附上截图） 在iOS下调用camera组件，ctx.takePhoto,保存下来的临时文件是png格式，导致体积超级大。但后缀仍然是jpg。我们从服务器下载后hexedit才发现这个问题。 - 预期表现 请保存成jpg，或者干脆给一个格式的控制权 - 复现路径 请看代码片段，会展示拍摄下来的文件长度，安卓和ios相差了10倍 - 提供一个最简复现 Demo 请看代码片段 找了几个之前论坛里的相同问题，均没有明确解决  camera 属性device-position 无法动态设置？  camera组件takePhoto拍出来的照片格式问题  wx.takePhoto IOS分辨率低文件大  这个是属于明确的bug，还请官方关注！

介于现在没有代码片段得不到重视，我就在这里做一个片段。但内容几乎和文档中的一模一样。 问题出现在我们系统测试中，发现上传的文件体积过大，速度非常慢：一个720x512的图片，在iOS下通过ctx.takePhoto 保存，居然有700k！！！而之前直接调用chooseImage compressed也不过就是700k，分辨率几乎是3倍。同时，发现android同样代码上传的文件体积只有80k，大小相差了接近10倍。 最后把文件拉到本地观察，发现iOS通过camera组件得到的图像文件，尽管后缀做成了jpg，事实上是一个png。所以导致了文件体积非常大的结果！ 还请小程序团队尽快尽快修复！

因为太简单只有wxml 我就不用片段了 以下{{racelogo}} 是一个静态的svg文件： http://cdn.raceonhills.com/cover/earthday2018.svg [代码]<[代码][代码]view[代码] [代码]class[代码][代码]=[代码][代码]"racelogo backimg"[代码] [代码]style[代码][代码]=[代码][代码]"background-image: url('{{raceLogo}}');{{logostyle}}"[代码][代码]></[代码][代码]view[代码][代码]>[代码] [代码].racelogo {[代码][代码]  [代码][代码]position[代码][代码]: [代码][代码]fixed[代码][代码];[代码][代码]  [代码][代码]height[代码][代码]: [代码][代码]300[代码][代码]rpx;[代码][代码]  [代码][代码]width[代码][代码]: [代码][代码]300[代码][代码]rpx;[代码][代码]  [代码][代码]bottom[代码][代码]: [代码][代码]814[代码][代码]rpx;[代码][代码]  [代码][代码]display[代码][代码]: flex;[代码][代码]  [代码][代码]border-radius: [代码][代码]50%[代码][代码];[代码][代码]  [代码][代码]left[代码][代码]: [代码][代码]50%[代码][代码];[代码][代码]  [代码][代码]transform: translateX([代码][代码]-50%[代码][代码]);[代码][代码]}[代码] 今天多个客户反馈部分安卓机器看到的svg非常模糊，但目前自己手中的小米并没有发现这个问题；见图 [图片] 因为问题太难定位并且很有可能是直接和微信内置浏览器相关，就直接在这里反馈了。在网上找到了之前QQ浏览器里一个类似的问题反馈： http://bbs.mb.qq.com/thread-198775-1-1.html 是不是哪次代码合并的时候出了差错？ 辛苦了~

昨天论坛里同时出现了我和其他几位开发者的关于突然读写剪贴板需要用户单次授权的问题： 当剪贴板内有内容时多了提示 wx.getClipboardData  突然弹出提示 监测剪贴板  一直弹出授权 点击确认 和取消后， 都会提出内容已复制 系统剪贴板多了弹窗提示 监测剪贴板 一直弹出层 好烦人， 如何清除黏贴版 还有这篇加急审核的 https://developers.weixin.qq.com/blogdetail?action=get_post_info&docid=000c44f0a80520af909660f9951800&highline=剪切板%7C%26弹窗&token=1934321849&lang=zh_CN 我们几位应该都是在首页onShow时使用了剪贴板内容，导致用户进入小程序就可以看到自己剪贴板的内容。并反复弹窗，这个对用户体验的伤害是灾难级别的。 昨天提交了临时屏蔽代码之后待审核，晚上团队对这个问题进行了激烈的讨论，最后决定彻底放弃对剪贴板实现页面routing的功能。这也让大家不需要等待这件事后续的调整结果了。 昨天在论坛里情绪激动，过了一夜之后平和点，但这里有一些对小程序团队，尤其是产品团队一些不得不说的话。 API的变更是否需要提前知会？ 对于影响下游研发、整体生态用户体验的上线，是否应该有一个健全的知会和上线流程？ 这次上线如果能先mp后台挂通知，然后文档先上线，再推基础库更新，这件事完全可以避免。我的观点里这个顺序应该是一个严格的流程，而到目前为止线上文档、开发者工具中仍然完全没有体现此次API体验变更的任何信息。我们小程序的客户也是微信的客户，现在大面积客户体验受影响是不争事实，这个在腾讯研发中算不算一个生产事故？ 剪贴板到底需要不需要授权？ 这完全属于讨论。我的个人观点是不需要； 一直非常支持也理解微信小程序在获取用户信息，本机电话，地理位置等等等等一系列用户隐私保护上做的设计，也一直觉得恰到好处。当然，监听并收集用户剪贴板里的内容到底有没有侵犯隐私的可能，这自然是肯定的。但这个可能性有多大？ 第一剪贴板和输入法不同，不是一个连贯连续的数据采集过程；剪贴板数据偶发性和随机性特别大，所以从采集的数据规模，提炼转化的投入产出来说，都不是一个值得去实践的侵犯方案，在小程序的准入、审核门槛下风险更小。对于读写剪贴板都需要单次授权，我个人觉得是得不偿失的。到目前为止，个人还不知道任何OS、平台在剪贴板的使用上采用这样单次授权的先例，这意味着碰到剪贴板操作授权对于用户来说，都是一个全新的安全体验，这里需要付出额外的思考成本是巨大的。而应用如果只是在某种场景下使用到剪贴板，但又不得不在入口处进行检查（如手机淘宝使用淘口令）这样的授权体验会让用户怎么想？本来是非常innocent的事，反而显得非常malicious。我觉得在这点上强化用户授权行为是没有必要的，消除evil是好的，但不能成一个witch hunt。 即使授权，需要在弹窗里显示剪贴板内容么？ 个人对这个设计也不理解。昨晚团队最终决定彻底割舍功能的原因，并不是完全因为有一个弹窗的干扰，而是因为这个弹窗会展示剪贴板的内容！我不知道产品经理自己是否实际体验过，这是有多么惊悚！现在大多数的移动设备都是不会关机的，而剪贴行为是一个偶尔发生的行为，但剪贴的内容往往比较重要且隐私，可能是一段领导需要传达的对话，可能是自己或者亲人或者客户的一个银行转账卡号，可能是懒得打字直接从哪复制，粘贴进入搜索引擎的一个搜索关键词。。。但这些信息都非常personal，往往复制和粘贴之间时间非常短，但粘贴之后，用户对于这段信息的期待是什么？就是除非我再粘贴，这东西就不应该再出现了，起码这个是从剪贴板被发明起就没有变化过的体验。但我们也不应该忘记，复制进入剪贴板行为是个偶发行为，剪贴板里的内容大多都是几个小时前、甚至几天前的内容；至少现在剪贴板还没有expire和判断时长的可能，所以请考虑这个场景： 我打开一个小程序给我朋友看某个有意思的页面，结果打开这个小程序时，跳出来了一个对话框，里面是我三天前复制粘贴进百度搜索的某个药品名称。。。。这是一个在任何情况下都不可被接受的场景。把这个问题换一个问法，微信小程序的产品经理，当您要求小程序只有用户授权才能操作剪贴板的时候，用户有授权微信展示他剪贴板内容在屏幕上过么？甚至在授权本机号码我们都会加几个****，PC上退出photoshop会提示“剪贴板里还有大量数据……”而不是把内容画在屏幕上， 为什么在这里展示剪贴板内容时候如此激进？难道都不是隐私内容么？这个内容足够隐私到小程序必须获取权限来获得机器判断的可能，但不隐私到可以暴露在屏幕上每次进入小程序都展示一次。。。。这是如何的自相矛盾。 即使授权，需要每次使用都弹窗么？ 这点其他帖子也提到了，原因显而易见。一般需要读取剪贴板的应用场景基本都是在逻辑主干上判断是否剪贴板里是一个特定会影响应用行为的数据。这个必须读了才知道，可能产品经理是想这个判断权放到用户手里，自己看看这个数据要不要给小程序读取？但这个现实么？另外每次都让用户判断的成本有多大？另外一些场景里，剪贴板内容可能也是由应用写入，用户理解不了，还是微信就是想消灭掉应用中使用剪贴板通信的可能？既然如此何必开放这个API？ 我们作为小程序研发者，公司可能整个业务都放在上面（以我们为例，我们没有h5，没有app，小程序是我们唯一的端）  几十个弟兄上上下下青春和财务都依赖微信生态，我们初心也简单，第一信任腾讯，第二相信小程序是解决我们业务场景的最佳不二选择，所以才这样没有backup的上。过往也会碰到各种bug和变动，但这一次，说实话伤害到了信任。这次提的4个问题，第1个问题，就跟昨天帖子里说的那样，这样不对，我们认为贵团队应该我们一个必要的说法。大家都是做研发，文档准确的重要性不言而喻不可儿戏。 第2，3，4问题，是我们坚持认为这个设计是一个错误，从我们狭隘的见识中，还看不到合理化解释的任何可能。这两点，真的只能说很遗憾。

我们的小程序中有类似手机淘宝那种根据复制的链接打开小程序直达某item页面的功能，因此在小程序启动时候就会获取一次剪贴板，用来判断routing。 今天发现iOS点开的时候，居然弹出了一个对话框，要求确认使用，现在成了每次到了首页都会这样。 大家都口口声声谈用户体验，这下体验怎么好了？用户只有某些情况下复制内容才有用，现在呢？每次进入小程序，都把 人家复制在剪贴板里的内容PO在屏幕上，万一是用户比较敏感的信息，他会如何看待我们这个小程序？？？这算不算暴露隐私？剪贴板的内容不应该没有用户粘贴，永远不应该在屏幕上展示么？ 文档里到目前都没有提过这个弹框，事前也没任何通知。现在我们面临保证用户体验隐私和拿掉重要业务功能模块的抉择！！ 请小程序团队一定要给我们一个说法！！

# 业务背景 由于应用场景经常在非网络情况下，所以需要通过类似资源包的方式将图片和数据缓存到本地。 # bug 之前都没有问题，png的图片都可以非常标准的 下载临时文件->保存临时文件 -> 替换image src中链接的方式实现。但发现如果缓存的文件为svg，则在 开发工具/iOS/Android中都无法呈现！ 还请小程序团队验证修复~