Firefox浏览器兼容性解答

Firefox 识别 @supports 没问题，但对某些新特性支持滞后或行为不同。比如 @supports (display: grid) 在旧版 Firefox（@supports (inset: 0) 在 Firefox 115+ 才开始支持，此前直接跳过整块规则。

实操建议：

• 查 caniuse.com 确认目标属性的 Firefox 起始版本，别只看“支持”就写死 @supports
• 避免嵌套 @supports (display: grid) and (gap: 1rem) 这类组合判断——Firefox 对复合条件解析更严格，可能因其中一项不支持而整条失效
• 用 getComputedStyle(el).display === 'grid' 做运行时兜底检测，比 CSS 规则更可靠

fetch() 在 Firefox 中遇到 CORS 预检失败

Firefox 对预检请求（preflight）的触发条件更敏感：比如带 Content-Type: application/json 的 POST 请求，在 Chrome 可能直发，在 Firefox 很可能卡在 OPTIONS 阶段并静默失败，控制台只显示 NetworkError when attempting to fetch resource。

关键原因不是服务端没配 CORS，而是请求头“越界”。常见踩坑点：

• fetch('/api', { headers: { 'X-Request-ID': 'abc' } }) —— 自定义 header 会强制触发预检，Firefox 尤其严格
• 用 mode: 'no-cors' 是无效解法，它会让响应变成 opaque，JS 无法读取 body
• 真正解法是服务端在 Access-Control-Allow-Headers 明确列出所有自定义头，且注意大小写（Firefox 区分大小写，X-Request-Id ≠ X-Request-ID）

Firefox 的 input[type="date"] 本地化与值格式

Firefox 渲染 时，界面语言跟随系统，但输入值永远是 YYYY-MM-DD 格式（ISO 8601），和 Chrome/Safari 一致。但容易忽略的是：用户用日历控件选中日期后，input.value 在 Firefox 中可能为空，直到焦点离开（blur）才更新。

这意味着：

• 监听 input 事件不如监听 change 可靠，尤其在表单校验场景
• 用 JS 设置值：el.value = '2024-05-20' 是安全的；但用 new Date().toISOString().split('T')[0] 更稳妥，避免时区导致的日期偏移
• 不要依赖 el.valueAsNumber——Firefox 不支持该属性，会返回 NaN

Firefox 的兼容性问题大多不是“不支持”，而是“支持得更保守”：API 被移除得早、预检更严、事件时机更滞后、属性暴露更少。盯住 MDN 页面右上角的 Firefox 版本支持表格，比查“是否兼容”更能避开坑。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《Firefox浏览器兼容性解答》文章吧，也可关注golang学习网公众号了解相关技术文章。