GCLI appcache validate fails for * in network section

RESOLVED FIXED in Firefox 32

Status

defect
RESOLVED FIXED
6 years ago
11 months ago

People

(Reporter: miker, Assigned: miker)

Tracking

Trunk
Firefox 32
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

STR:
1. Go to http://appcachefacts.info/demo/
2. Open GCLI
3. appcache validate

Output:
...
NETWORK section line 36 (*) prevents caching of line 36 (*) in the NETWORK section.
...

This is obviously wrong.
Duplicate of this bug: 981771
I'm having a similar issue with my manifest (available if necessary but it's for a private site). 

Running appcache validate yields:

FALLBACK section line 123 (/ offline.php) prevents caching of line 123 (offline.php) in the FALLBACK section.

When I try putting offline.php in the explicit cache section, I get a message like:

URI https://[...]/offline.php is referenced in multiple locations. This is not allowed: [{"line":8,"section":"CACHE","original":"offline.php"},{"line":370,"section":"FALLBACK","original":"offline.php"}].

The original manifest works in IE11, Chrome stable+, Chrome for Android, and iOS Safari (I am experiencing a separate issue in OSX Safari).

Is there any way to get better debugging information? Right now all I am able to see is that applicationCache.status is uncached and it is triggering the error event.
I have some more unanswered questions in addition to the one from my previous post:
- Does this incorrect behavior exist only in the GCLI appcache validate code or also in the browser code? It's not clear if they are using different logic.
- Is the Application Cache going to be developed/supported further by Mozilla? or is the ServiceWorker specification taking precedence? It seems like there isn't any development effort focused on this and related issues.

Please let me know if there is a more appropriate place to ask these questions.

Thanks.
(In reply to Dev from comment #3)
> I have some more unanswered questions in addition to the one from my
> previous post:
> - Does this incorrect behavior exist only in the GCLI appcache validate code
> or also in the browser code? It's not clear if they are using different
> logic.

This is purely a bug in the validation logic. This logic has to be separate because e.g. we check that all files are available and can be downloaded etc. and this would slow down normal webpages. Saying that, if you log a bug we could add some appcache errors to the console output.

> - Is the Application Cache going to be developed/supported further by
> Mozilla? or is the ServiceWorker specification taking precedence? It seems
> like there isn't any development effort focused on this and related issues.
> 

Both the appcache and ServiceWorker are being worked on. The only reason we haven't got around to fixing this is because it is a lesser used DevTools feature and we need to prioritize bugs that affect more users.

This is a fairly simple bug to fix so I have added some flags to make that clear ([good-first-bug][lang=js][mentor=mratcliffe]). If you are good with JS I would be happy to help you look into this bug.

> Please let me know if there is a more appropriate place to ask these
> questions.
> 
> Thanks.
Whiteboard: [good-first-bug][lang=js][mentor=mratcliffe]
Whiteboard: [good-first-bug][lang=js][mentor=mratcliffe] → [good first bug][lang=js][mentor=mratcliffe]
Depends on: 983871
Whiteboard: [good first bug][lang=js][mentor=mratcliffe]
Fixes cases for all of the above.
Attachment #8416481 - Flags: review?(pbrosset)
Comment on attachment 8416481 [details] [diff] [review]
appcache-network-section-981758.patch

Review of attachment 8416481 [details] [diff] [review]:
-----------------------------------------------------------------

Seems good to me
Attachment #8416481 - Flags: review?(pbrosset) → review+
Whiteboard: [land-in-fx-team] → [fixed-in-fx-team]
https://hg.mozilla.org/mozilla-central/rev/ede61596f872
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Whiteboard: [fixed-in-fx-team]
Target Milestone: --- → Firefox 32
Product: Firefox → DevTools
Product: DevTools → DevTools Graveyard
You need to log in before you can comment on or make changes to this bug.